Hi Koen, I agree with you on one and three.
jBPM works, great, solves all problems and there is at the moment no mission critical need for real concurrency. It is/was important for me to know the limitations because I am using JMS intensively (mainly for transaction reasons) and have to guard against concurrency problems. The conclusion of this Thread for me is: lock on processInstance. Which is fine for me, but effectively means no real concurrent execution. We can leave it at that. Everything from now on is purely academic. (I haven't been to the office for the last week due to a flu and do not (yet) have jBPM or other tools set up at home, so this will look a bit cheap but it should make the point.) A technical (not business) usecase true concurrency a) workload in jBPM actions: | thread1................. | tx1..................... | <start/> | | <fork/> | | <state a> <state b> | <action> <action> | <send JMS> <send JMS> | continue in new Thread continue in new Thread | (thread2) (thread3) | </send JMS> </send JMS> | </action> </action> | </state a> <state b> | tx1..................... | thread1................. | | thread2..... thread3..... | tx2......... tx3......... | <MDB> <MDB> | signal() signal() | | <state c> <state d> | <action/> <action/> | </state c> </state d> | | <state e> <state f> | <action/> <action/> | </state e> </state f> | | !!!!!!!!!! | | <join/> <join/> | </MDB> <MDB> | | ?????????? | | tx2......... tx3.......... | thread2..... thread3...... | The point Sean made was that if tx2 and tx3 happen concurrently, when reaching the Join node both will not recognize that the other has possibly finished and neither will therefore continue. You can circumvent the problem from above if you delegate all workload to MDBs b) all workload in MDBs: | thread1................. | tx1..................... | <start/> | | <fork/> | | <state c> <state d> | <action> <action> | <send JMS> <send JMS> | </action> </action> | </state c> </state d> | | <state e> <state f> | <action> <action> | <send JMS> <send JMS> | </action> </action> | </state e> </state f> | <join/> | tx1..................... | thread1................. MDBa, MDBb, MDBc, MDBd do their stuff totally idependently. But then the execution or rather failure of e.g. <state f> could not rollback <state d> (not the sending of the JMS message, the failure of the workload.) so this isn't the szenario I would want to use. Koen, you've mentioned it a few times before yourself. Its a concurrency issue that doesn't go away with messaging. When you think about it there will be no simple solution to it. And once again: Have a very Merry Third Advent, sing Christmas jingles, go drink Glühwein on a Weihnachtsmarkt and don't go looking for blonde D-Cups. Rainer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3911956#3911956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3911956 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
