Hi Raj, quick answer to the threads: don't do it. It won't work. Never, ever.
This has been discussed in several threads. Executing workflows writes logs, logs are on a processInstance level. Concurrently executing causes concurrent writes to the processInstance => causes persistence problems. Even without the logs there are shared variables, etc. => Don't do it. Unless.... ... you realy have divided your functionality so far that you concurrent threads have NO knowledge / access to the processInstance (this would have to be the case with a JMS solution to). Give the threads the information to do work and signal back (after acquiring a lock on the processInstance) But... ... if you would have done that you wouldn't get concurrency problems :-) Now to the trivial: Hibernate uses "select for update" to acquire locks so the processInstance will be locked for the duration of your transaction. (You are running in defined transactions?) Does that help? Greetings View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3925545#3925545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3925545 ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
