Hi Anurag,

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, which is:

            transactionOwner = txm.begin();


            persistenceContext.persist( this.sessionInfo );

            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

has method execute() which is synchronized and is entry point to all jbpm functionality

We 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

I wanted to understand the reason for this method being synchronized and what would be required to make it non-synchronized

I would be thankful for any advice/help 


jbpm-dev mailing list

jBPM/Drools developer
Utrecht, the Netherlands