Ronald, >> Examples often do 'wrong' things..
I think you're suggesting that this isn't a real use case. I think I see your point -- without any asynchronous behavior, the two branches are serialized and so might as well be modeled as a straight line. But imagine an actionhandler that may enter a wait state (not signal, but wait for an external signal) or not, dependent on some condition. In this case, a fork might make sense, but in some conditions would fail as described. In general, I think these kinds of problems should be fixed, regardless of whether it seems to be a real-world case. ["These kinds of problems" is vague, and vulnerable to reductio ad absurdum.] They reduce confidence in JBPM and give it a "bad taste". If it seems broken, it might as well be broken. >> What is the issue here is that there is no wait state where the process is >> persisted, so everything happens in one 'transaction'... and both update the >> same token... Agreed. A good fix is complex... this is another of those cases where the correct fix will depend on whether the deployment is single-threaded, multi-threaded/single-server, or multi-threaded/multi-server. I wrote a fix that queues up a job to do the parent-token work in Join... but it's only a good fit for one or two of those three deployment scenarios. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061423#4061423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061423 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
