Hi Raj, check out the various threads on this subject. This has been discussed in extreme detail.
As I mentioned there are good reasons not to spawn threads. One would be that you are simply not allowed to do so in a J2EE environment. The others lie in the concept and implementation details of the processInstance. While missing concurrency sounds like a problem, I'm not quite sure it realy is, at least I haven't seen a use case that requires concurrency. a) if the execution time of the concurrent paths is short (quickly executing Actions) you will not realy notice the missing concurrency. b) if they are long running you can execute the long running parts asychronously (roll your own JMS stuff or use the new feature in 3.1) c) if they require user interaction you will need telepathic siamese twins to get concurrent user interaction d) if your concern is CPU utilisation (as is mine with two 16GB, 4CPU Suns in a cluster :-) you will need to have a workload backlog lined up to fully use those anyway, concurrency or no concurrency. So my answer to your question is another question: what is the use case for Java concurrency in jBPM? This does not give you concurrency, but maybe you don't even need it... (I'm not aware of what the jBPM Team is planning on this, though.) Greetings View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3923423#3923423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3923423 ------------------------------------------------------- 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
