Drawback of DB Replacement - SQLite by H2

[LevelX]

The H2 db solution has a big drawback. You can't open two clients using the same db now.

Code: Select all

org.h2.jdbc.JdbcSQLException: Database may be already in use
at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)


North can you check if it's possible to handle this in a way that multiple clients can be started?
Because for testing purposes I use this all the time.
If not, I'm voting to go back to SQLite.

[North]

You can use the "cheat" feature to control what cards your opponent has and what you have. After I found out about this, I don't think I've started two clients again.

I can see there are some scenarios where you need to control how the cards are played and you would need two clients. For such scenarios I propose the developer uses a local change to use a sqlite db. Here is how the workflow would be:
1. You change it to sqlite in the pom and in the 2 java classes.
2. You test your changes
3. You commit only your changes
4. git stash (this puts all your uncommited changes in a temporary commit)

Now, whenever you want to test using two clients you do like this:
1. git stash pop (this also removes your temporary sqlite changes and you will have to use git stash again to save it)
2. test
3. commit your changes
4. git stash (sqlite changes)

Please let me know if this is too troublesome.

[LevelX]

Sounds a bit too troublesome. I test a lot of tournament handling, or such things as the concede behaviour. So you often need multiple clients.

What about a config value for the client that defines if SQLite or H2 is used for the DB?

So we can default it to H2 and a developer can set it to SQLite (as long he doesn't use a MAC).

[noxx]

May it help?

http://stackoverflow.com/questions/8158969/h2-database-error-database-may-be-already-in-use-locked-by-another-process

[LevelX]

May it help?

http://stackoverflow.com/questions/8158969/h2-database-error-database-may-be-already-in-use-locked-by-another-process

To open the H2 in TCP mode would allow all developers (also MAC users), to open multiple applications using the same DB to avoid the DB locked error.
I guess with the slower db I can live, so a good solution in my opinion.

Robert what do you mean?

[North]

We can use a VM argument like the test one for starting it in TCP mode. Otherwise it will be started in embedded mode. Using this approach we can always start the server using the embedded mode, while we can choose to start the client using the TCP mode.

What do you think of using this approach?

[LevelX]

We can use a VM argument like the test one for starting it in TCP mode. Otherwise it will be started in embedded mode. Using this approach we can always start the server using the embedded mode, while we can choose to start the client using the TCP mode.

What do you think of using this approach?

Assuming the TCP mode allows really access from multiple XMage-Clients it would be a perfect solution for me.

[North]

I used automatic mixed mode to fix this issue. It automatically starts the server in embedded mode and creates the server on an available tcp port. The first client to it will have the same speed as using it in file mode but allows a second client to connect to this DB.

The good thing about this is that there is nothing special that needs to be added to the VM arguments and works just fine out of the box.

[LevelX]

Good finding, Robert I guess the perfect solution.
So I tested it and it works to use multiple clients.

However the other databases "feedback" and "mage" should also be opened in the automatic mixed mode to avoid locking problems. Now I get messages the DB's can not be read because of existing locks.

Code: Select all

feedback.h2.mv.db could not be read: Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat   
mage.h2.mv.db could not be read: Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat   

[North]

they are already using the automatic mixed mode. I tried this and I don't have any issues with it.

Those DBs don't really need automatic mixed mode seeing as how they are only used by the server but I did add it in case the client gets pretentious.