You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the session factory is closed, the integrator calls the ConfigurationHelper configureDefaultProperties() with a null set of properties. This causes the session factory to be removed from the DEFAULT_PROPERTIES hash, but not from the JDBC 42 hash. Repeated invocations of the Configuration Helper (as in unit tests that recreate the database and the session factory) will continue to add new session factories to the JDBC 42 hash - thus running large unit test suites out of memory.
The text was updated successfully, but these errors were encountered:
Experienced the same problem running with version 3.2.0 GA. In the context of Spring Batch we refer to several databases all whose session factory gets hashed in the ConfigurationHelper. After multiple executions of the batch process we experienced OutOfMemoryExceptions due to exceeding heap space. Using VisualVM we saw the same problem described by @kidnme where references to session factories were still in memory via the ConfigurationHelper JDBC42 hash. Our solution was to rollback to version 3.1.0 CR10 until this is resolved.
When the session factory is closed, the integrator calls the ConfigurationHelper configureDefaultProperties() with a null set of properties. This causes the session factory to be removed from the DEFAULT_PROPERTIES hash, but not from the JDBC 42 hash. Repeated invocations of the Configuration Helper (as in unit tests that recreate the database and the session factory) will continue to add new session factories to the JDBC 42 hash - thus running large unit test suites out of memory.
The text was updated successfully, but these errors were encountered: