FILE_LOCK=SERIALIZED versus AUTO_SERVER=TRUE

[LRichard]

Since we're experiencing several problems with the SERIALIZED lock mode, we look at alternatives and the AUTO_SERVER mode strikes back.
The nice explanation from Christian shows that the AUTO_SERVER mode should meet our needs.
However, we are concerned by the following assertion from the Features page (that's why we initially excluded the AUTO_SERVER mode) :

If the first connection is closed (the connection that started the server), open transactions of other connections will be rolled back (this may not be a problem if you don't disable autocommit).

Our application uses transactions. These transactions are however not opened for a long time (hibernate generally caches statements of one transaction to send them all at a time). How is the rollback handled when the server stops ? Is there a way to tell the server not to stop until all opened transactions are closed ? In this closing phase (that should be brief), the server would not accept any new transaction.
If there is no way to prevent a rollback to happen in the middle of a transaction without the client being aware of it, I'm afraid we won't be able to use the AUTO_SERVER mode.
If the client whose transaction has been rolled back is told it (with a JDBC exception on the next statement in the transaction or on the commit), it should be OK. Is it the case ?

We will test this use case as soon as we can but any clue will be welcome.

Laurent

[LRichard]

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