Bug 848855 - Transaction rollback failure after concurrent access: no transaction!
Summary: Transaction rollback failure after concurrent access: no transaction!
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM Console
Version: BRMS 5.3.0.GA
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: ---
Assignee: Kris Verlaenen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-16 15:19 UTC by Jiri Locker
Modified: 2023-05-31 22:25 UTC (History)
1 user (show)

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.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
server.log (203.15 KB, text/plain)
2012-08-16 15:19 UTC, Jiri Locker
no flags Details

Description Jiri Locker 2012-08-16 15:19:28 UTC
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

Comment 1 Maciej Swiderski 2012-08-23 16:49:40 UTC
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.

Comment 2 Jiri Locker 2012-08-24 12:29:24 UTC
(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.

Comment 3 Maciej Swiderski 2012-08-24 12:41:22 UTC
(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?

Comment 4 Maciej Swiderski 2012-08-29 09:22:57 UTC
pull requests are ready:
drools https://github.com/droolsjbpm/drools/pull/139
drooljbpm-integration https://github.com/droolsjbpm/droolsjbpm-integration/pull/36

Comment 5 Maciej Swiderski 2012-08-29 18:33:47 UTC
merged into 5.3.x and master for both drools and droolsjbpm-integration

Comment 6 Radovan Synek 2012-09-14 10:49:24 UTC
Verified on 5.3.1.BRMS-ER1

Comment 7 Radovan Synek 2012-10-05 13:29:29 UTC
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.

Comment 8 lcarlon 2012-10-22 04:46:22 UTC
Doc text has been edited for inclusion in the release notes. Thanks for providing the text, Maciej.

- Lee


Note You need to log in before you can comment on or make changes to this bug.