We are running into out of memory issues in our Java application that we've narrowed down to objects being retained by H2. We ran into this issue after upgrading from 1.4.200 to 2.1.210. We are using H2 in-memory (no file store) with auto-commit enabled. We created a simplified test in which we add tables and then drop them, we see some H2 objects still exist in memory (analyzed via YourKit). The maps entries in MVStore are not getting cleared out when tables are dropped. Running the identical test using the previous 1.4.200 version does not experience this behavior. Below are screenshots of YourKit while running a simple test application that reproduces the issue:

1.4.200 after adding tables and before dropping:

1.4.200 after dropping tables and manually performing GC:

2.2.210 after adding tables and before dropping:

2.1.210 after dropping tables and manually performing GC:

We see during debugging that commit() is not being invoked on MVStore from TransactionStore.endTransaction(). A change was made in #3145, to avoid calling commit() when not using a file store. Since MVStore.commit() ultimately ends up invoking the logic that removes the maps entries, this seems like a memory leak when using an in-memory DB. Removing the if (store.getFileStore() != null) { check from TransactionStore.endTransaction() allows MVStore.commit() to be called and cleans up the map in the same manner as 1.4.200.

Can you provide insight into the following?

1. Is there more background on why the check was added to TransactionStore?
2. Are there any side effects to removing this check?