Sorry for the late answer.
The reason that SSCS.execute() is synchronized is that you could
otherwise encounter race conditions.
It's been a while since I've looked at that code, but if I
remember correctly, it has to do with what execute() really does,
transactionOwner = txm.begin();
txm.commit( transactionOwner );
If you had threads concurrently executing this code with a JTA
transaction (on the same session), it's possible that, for
example, this could happen:
Thread A: txm.begin()
Thread B: txm.begin() // no-op because _not_ the txOwner!
Thread B: registerRollbackSync(), joinTransaction(), persist(),
Thread B: txm.commit() // no-op, because _not_ the txOwner!
Thread A: registerRollbackSync(), joinTransaction(), persist(),
Thread B: txm.commit() // overwrites the persist from
Thread B, even though thread B should have finished 2nd.
Also, there are also race conditions in which commits will fail
because a thread that does not own the transaction will commit
after the tx has been closed.
I'm pretty sure that that's the problem -- does that make sense?
07-12-12 08:55, Anurag Aggarwal:
I am using jbpm and drools at Intalio and recently we were
looking into performance, and found an issue that in persistence
the following class
method execute() which is synchronized and is entry point to
all jbpm functionality
were trying to update many process instances at same time and
seems because of above they are updated one after another and
not in parallel
wanted to understand the reason for this method being
synchronized and what would be required to make it
would be thankful for any advice/help
jbpm-dev mailing list
Utrecht, the Netherlands