-
Bug
-
Resolution: Unresolved
-
Major
-
5.4.0.Final
-
None
Transactions are leaked whenever LockTokens are involved in a session when using file-based DB.
If you leave the system running for a prolonged amount of time, at some point you will encounter this exception:
Caused by: java.lang.IllegalStateException: There are 65535 open transactions [1.4.191/102] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773) at org.h2.mvstore.db.TransactionStore.begin(TransactionStore.java:236)
How to reproduce:
It is easy to reproduce using this sample snippet:
try { // Prerequisite is to have a node with an open scoped lock on: String validNodeId = "0afaaa3a-b751-4624-b51e-43db07c164c0"; String nodeOpenScopedLockToken = "4f5384fc-8fcf-40f6-b37a-24691a99d7e7"; SystemHttpServletRequest httpServletRequest = new SystemHttpServletRequest("DummyUser"); ServletCredentials credentials = new ServletCredentials(httpServletRequest); Session session = repository.login(credentials); Node node = session.getNodeByIdentifier(validNodeId); session.getWorkspace().getLockManager().addLockToken(nodeOpenScopedLockToken); // Call ends up going to FileDb.begin(), which opens one MVStore transaction with ID 1 // Do operations on node here if you wish, not needed to reproduce bug session.save(); // Call also goes to FileDb.begin(), opens up transaction with ID 2 session.logout(); // Call also goes to FileDb.begin(), opens up transaction with ID 3 } // End of Java EE transaction calls FileDb.txCommitted(), which closes transaction with ID 1, but not ID 2 and ID 3
Attach a debugger to MVStores TransactionStore, inspect the variable OpenTransactions, every time the above snippet is run, there is two leaked entries.