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();

            registerRollbackSync();

            persistenceContext.joinTransaction();
            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?


Marco

07-12-12 08:55, Anurag Aggarwal:

-- 
jBPM/Drools developer
Utrecht, the Netherlands