Hide Forgot
Description of problem: When a ksession is not disposed between multiple invocations (like by the strategy "one or pull of ksessions per cluster member") together with BRMS Spring integration, the memory usage keep growing after each interaction with the process and some times the exception StaleObjectStateException could occur even without concurrent access to the process. Process instances in Spring are loaded using the application context, not the command context. This can cause OptimisticLockingExceptions if the process instance was modified elsewhere, as this context is not cleared in between invocations. Using the command-scoped context will make sure that process instance changes between invocations are picked up at the beginning and don't cause a commit exception at the end. It is the product 5.3 BZ for the community Jira https://issues.jboss.org/browse/JBPM-3964
Verified with BRMS-5.3.1-P05 that: 1. multiple invocations of single ksession does not increase memory usage. 2. using 2 nodes with the reproducer application attached to corresponding support case and following the reproducing steps does not produce any transaction related exceptions.