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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...