So we tested what happens in auto mixed mode when the server shutdowns.
It's finally the same logical behavior as with a standard server : the
client whose transaction is not closed receives a dedicated "session
closed" exception at the next statement :
Exception in thread "main" org.h2.jdbc.JdbcSQLException: Connection is
broken: "session closed" [90067-162]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.engine.SessionRemote.checkClosed(SessionRemote.java:500)
at org.h2.engine.SessionRemote.removeServer(SessionRemote.java:431)
at org.h2.command.CommandRemote.prepare(CommandRemote.java:80)
at org.h2.command.CommandRemote.<init>(CommandRemote.java:46)
at org.h2.engine.SessionRemote.prepareCommand(SessionRemote.java:437)
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1121)
at ...
This is fine for us since such an exception is caught by our application.
Its state is then not changed and database access can be retried on user's
demand.
Moreover, accessing the database when the first client quits and stops the
server should be very rare in our cases.
In conclusion, I think we will definitely privilege AUTO_SERVER over the
SERIALIZED file_lock in most of the situations, the latter being too
sensitive to timing and the underlying file system.
For now, we are going to execute some stress tests that failed with
SERIALIZED file_lock mode and see how they behave in AUTO_SERVER mode.
Laurent
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/h2-database/-/sZRfUXFm5r4J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
