Bug 848855
| Summary: | Transaction rollback failure after concurrent access: no transaction! | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Locker <jlocker> | ||||
| Component: | jBPM Console | Assignee: | Kris Verlaenen <kverlaen> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | BRMS 5.3.0.GA | CC: | kverlaen | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Business process instances could not be accessed concurrently when Jboss Enterprise BRMS was clustered due to the persistence context not being cleared. This prevented single process instances from being managed by JBoss Enterprise BRMS in a clustered environment. To resolve this issue, the persistence context is now cleared on the transaction boundary level, and process instances can be managed in a clustered environment.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-02-10 03:20:31 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
what you mean by "jbpmSession.ser is shared between business-central instances"? This file is written into jboss.server.temp.dir which should be dedicated to a given instance. Do you manually transfer this file from one instance to another? In general, using same sassion on two parallel processes (in this case server instances) is not recommended due to concurrency problems on data base. (In reply to comment #1) > what you mean by "jbpmSession.ser is shared between business-central > instances"? > > This file is written into jboss.server.temp.dir which should be dedicated to > a given instance. Do you manually transfer this file from one instance to > another? Yes, that's basically what I did. > In general, using same sassion on two parallel processes (in this case > server instances) is not recommended due to concurrency problems on data > base. I thought that was the requirement for having two clients share the same set of processes, which is vital for group of jbpm engines (business centrals) co-operating in cluster. Anyway, sharing jbpmSession.ser is not necessary to reproduce the exception. I managed to do so even if each business central had it's own session id generated. (In reply to comment #2) > (In reply to comment #1) > > what you mean by "jbpmSession.ser is shared between business-central > > instances"? > > > > This file is written into jboss.server.temp.dir which should be dedicated to > > a given instance. Do you manually transfer this file from one instance to > > another? > > Yes, that's basically what I did. > > > In general, using same sassion on two parallel processes (in this case > > server instances) is not recommended due to concurrency problems on data > > base. > > I thought that was the requirement for having two clients share the same set > of processes, which is vital for group of jbpm engines (business centrals) > co-operating in cluster. if process does not rely on session state (facts in it, timers) them any session can be used to work with process instance as it is stored separately in data base. > > Anyway, sharing jbpmSession.ser is not necessary to reproduce the exception. > I managed to do so even if each business central had it's own session id > generated. Could you provide steps how to reproduce it, and is that reproducable only on multi node environment? pull requests are ready: drools https://github.com/droolsjbpm/drools/pull/139 drooljbpm-integration https://github.com/droolsjbpm/droolsjbpm-integration/pull/36 merged into 5.3.x and master for both drools and droolsjbpm-integration Verified on 5.3.1.BRMS-ER1 More reliable way to reproduce (without session sharing): 1. Prepare some JBPM process in Guvnor. 2. Launch two BRMS cluster nodes. 3. Open business-central instance#1 and launch the process. 4. Open the second business-central (instance#2) - launch the same process. 5. Return to business-central instance#1 - after refreshing you should see the error instead of both launched process instances. Doc text has been edited for inclusion in the release notes. Thanks for providing the text, Maciej. - Lee This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |
Created attachment 604969 [details] server.log Description of problem: Consider jBPM cluster created by deploying business-central + jbpm-human-task into brms-standalone (EAP5) cluster (two nodes). jbpmSession.ser is shared between business-central instances so that both of them operate on the same session. Commands issued from one console instance update persisted entities and increment their versions (optlock attribute). When such command is issued on both console instances concurrently the transaction commit fails and subsequently the attempt to rollback it fails too. The command is not successfully performed. Version-Release number of selected component (if applicable): 5.3.0.GA How reproducible: always Steps to Reproduce: 0. prepare some jBPM processes in Guvnor 1. launch two BRMS cluster nodes 2. access business-central instance #1 (let it create new session id 1) 3. access business-central instance #2 (make sure it loads session id 1) 4. in business-central #1 start a process, read the exception Actual results: squeezed stack trace: org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Could not commit session or rollback Caused by: java.lang.RuntimeException: Could not commit session or rollback Caused by: java.lang.RuntimeException: Unable to rollback transaction Caused by: java.lang.IllegalStateException: BaseTransaction.rollback - [com.arjuna.ats.internal.jta.transaction.arjunacore.notx] [com.arjuna.ats.internal.jta.transaction.arjunacore.notx] no transaction! Expected results: The operation should be completed even if the transaction commit fails due to accessing a stale object updated by a different transaction. Additional info: see full server log attached