Re: [rules-dev] [jbpm-dev] synchonizated method in SingleSessionCommandService

[Marco Rietveld]

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: Hi, 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 org.drools.persistence.SingleSessionCommandService 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  Regards, Anurag _______________________________________________ jbpm-dev mailing list jbpm-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev -- jBPM/Drools developer Utrecht, the Netherlands

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev