Bug 805899 - BaseTransaction.rollback - no transaction! occurs occasionally when multiple threads use persistence
BaseTransaction.rollback - no transaction! occurs occasionally when multiple ...
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity high
: ---
: BRMS 5.3.0.GA
Assigned To: Marco Rietveld
Jiri Svitak
: 803831 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-03-22 07:47 EDT by Jiri Svitak
Modified: 2016-09-20 01:04 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-05 06:57:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Hudson job log with exception (150.00 KB, text/plain)
2012-03-22 07:47 EDT, Jiri Svitak
no flags Details
Test Log output from ProcessMultiThreadPersistenceTest (44.40 KB, text/plain)
2012-04-17 14:01 EDT, Marco Rietveld
no flags Details

  None (edit)
Description Jiri Svitak 2012-03-22 07:47:49 EDT
Created attachment 571973 [details]
Hudson job log with exception

This exception occurs only sometimes when running multiple threads with persistence:

[java] 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!
[java] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:161)
[java] 	at org.drools.persistence.jta.JtaTransactionManager.rollback(JtaTransactionManager.java:191)
[java] 	... 7 more

The whole test log is attached.

Tests starts three threads. Threads share persistence configuration (persistence tested with MySQL and Oracle). Every thread runs 100 loops. Each loop runs two or three process instances and waits for their completion. user-task thread uses test handler for completing work items. Transactions (com.arjuna) are handled by jbpm, no explicit call of start(), commit() or rollback().

This one is difficult to reproduce, because it looks like a concurrency issue.
Comment 1 Jiri Svitak 2012-03-29 08:52:48 EDT
I have created a pull request with a test case. You have to run for example 100 loops to see that sometimes the exception is thrown.
Comment 2 Marco Rietveld 2012-04-11 07:04:33 EDT
*** Bug 803831 has been marked as a duplicate of this bug. ***
Comment 3 Marco Rietveld 2012-04-11 17:37:56 EDT
I've gone through the tests today. As far as I can tell, the bug that's showing up in the logs is because the test -- even though Thread.join() was being used -- was ending before the threads using persistence were done. 

This meant that the @After method was called in which, among other things, the Bitronix transaction manager was cleaned up -- while the test threads were still running. 

Once I made sure that the tests waited until the threads completed, then this bug no longer happened. 

A bug that I did see is that not all threads were started and/or completed -- regardless of whether persistence was used or not. But this seems to be related to the amount of memory/thread limits being used in the JVM. 


In short, I'd like to reject and close this bug because I can not find any evidence that there is a problem with concurrency and persistence. 

If you find anything that says otherwise, please let me know. Otherwise, I would like to close this bug by the end of the week.
Comment 4 Jiri Svitak 2012-04-16 04:28:24 EDT
I do not agree. The @After method is called only after the whole test. Exceptions were occurring randomly during the test. What you say would mean that @After method is called after each loop, which is not true. 

Maybe the problem will occur also without persistence, but I thought that since the exception comes from transactions, then it's persistence dependent problem.
Comment 5 Marco Rietveld 2012-04-16 15:29:21 EDT
If these problems are still occuring with you, could you do the following for me? 

- Add a System.out.println (or similar) to the @After method so that we know exactly when it fires in the test. 
- Please than also attach a log to this bug of the test failing.  

Comment 6 Marco Rietveld 2012-04-17 14:00:47 EDT

See the attached test-log for an exception that occurs. 

This exception occurs because there are 2 knowledge sessions and is a known bug. Fixing this bug is out of scope for BRMS 5.3 -- I've checked this with Mark. 

It is currently not recommended to run multiple processes on different knowledge sessions. 

If there is only one knowledge session, then there is a synchronized method that ensures that each process's persistence logic happens in isolation -- and not simultaneously with the persistence logic of another process. 

However, if there are multiple knowledge sessions, there is no way to ensure that different processes (on the different knowledge sessions) don't simultaneously interact with the database. 

When they do simultaneously interact with the database, there's a possible deadlock situation that's shown in the log I attached: one knowledge session/process has a lock on the SessionInfo table while the other one has a lock on the ProcessInstanceInfo table. 

I haven't been able to recreate the bug/stacktrace that this bug is about.
Comment 7 Marco Rietveld 2012-04-17 14:01:28 EDT
Created attachment 578116 [details]
Test Log output from ProcessMultiThreadPersistenceTest
Comment 8 Jiri Svitak 2012-04-18 05:48:50 EDT
Thanks for your findings about this issue. If this issue is not going to be fixed in BRMS 5.3.0, then at least documentation about multithreading should be updated to exactly describe what is the jBPM capable of.
Comment 9 Marco Rietveld 2012-04-20 17:43:37 EDT
I've updated the documentation.
Comment 10 Ryan Zhang 2012-04-23 03:37:35 EDT
Update status to ON_QA. Please verify them against ER6.
Comment 11 Ryan Zhang 2012-04-23 03:52:02 EDT
Confirmed that not picked in ER6. Change status back.
Comment 13 Jiri Svitak 2012-12-05 06:57:52 EST
This bug won't be fixed in BRMS 5.3.x. If the problem will be found in future versions, a new bug will be reported. Closing the bug.

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