You might find the discussions in the "Token.signal() ---> 2 tokens?" thread useful...
pojomonkey, thanks for the reply. However, I don't think it helped me. My current code signal()s the tokens within the fork, and should thus be correct. In fact, perhaps to clarify, when the signal()s are executed in sequence, no exceptions occur.
Oh, and I'm using jBPM 3.1.4 btw
look in the jira... there is info there about SOE....
We too use forks, joins and sub proceses extensively with async nodes. StaleObjectExecption have been in issue for us with JBPM 3.2.2.
Our problem isn't in the fork, but the join that follows.
In November a fix was made to Join.java where they added a flush. I pulled a copy of this file into our code base. There is a Jira issue for this. Tom Baeyens checked in the code in November. But I can't find the issue number. If you look at the CVS history for Join.java you should see the change.
This significantly helped elimate the most of our StaleObjectExceptions. We would get a StaleObjectException frequently when two or more async sub-processes finished and both their next transitions were into the same Join node.
We just discovered another issue with Join and StaleObjectExcption. If two or more of the transitions coming into the join are executed at the same time so the Join.execute method is called by multiple threads simultaneously. Each thread tries to updated the parent token and a StaleObjectException results. We are trying to create a unit test that reliable produces the problem. At the moment it is a race condition so it doesn't happen everytime.
Hope this helps.
estaub> Already using READ_COMMITTED, unfortunately no effect
jeffj55374> Thanks for the info, upgrading jBPM may not be an option, so we'll have to resort to writing some custom locking code I guess...
upgrading jBPM may not be an option, so we'll have to resort to writing some custom locking code I guess...
hmmm.... upgrading to a stable, released new version of jBPM is no option, patching an older version with custom, not tested, temporary code is? what are you running? 3.0? since upgrading from 3.1 is fairly easy.
Was this issue for the join with multi-threads fixed?
I am facing same issue, too.
My application server is Oracle, IBM, and Fujitsu with Oracle 10g DB.
I have two parallel asynchronous nodes between fork and join, and these node are executed by different thread via MDB.
Here is what I understood from code so far.
In execute method in Join node, when it call session.lock(parentToken, LockMode.FORCE), hibernate seems like incrementing version (why for locking???), and same operation to the same object in another thread throw StaleObjectStateException.
This is basic feature we need for concurrent operation, and very easy to implement with SQL based programming with "select for update".
I tried to LockMode.UPGRADE, but it's same.
So, I tried to called "select for update" against parent Token record instead of using session.lock(), and this operation worked as I expected, but when committing transaction on JbpmContext.close(), later thread still throw StaleObjectStateException.
OK, then I load object after getting lock (after select for update) by session.load(parentToken.getId(), Token.class, LockMode.UPGRADE), but surprisingly the parentToken object returned still had old version, even DB record was committed and version was incremented.
Does someone solve this issue?
or am I doing something wrong?