I suspect there are more problems here.
If I'm not mistaken, when an actionhandler is invoked, the transaction will have
started at the last asynchronous event that caused something to be written persistently.
If all the nodes are asynchronous, this is fine. But if there's a sequence of
synchronous nodes, the process may unwind quite far back. This seems like it would be
surprising to the developer. If any of the external actions in the rolled-back sequence
aren't transactional, the process will now be "skewed", living in the past,
relative to the real-world process being performed, probably waiting for an event that has
already happened and now will never occur again.
If there are any actionhandlers or other elements that may or may not signal
synchronously, the amount of rollback becomes somewhat unpredictable. This is common when
waiting for an event that may have already happened, e.g., a timer that may have already
expired.
I'm not saying that the JBPM internal process integrity is lost, just that the
distance rolled back in the graph seems likely to be unexpected and/or uncertain, and
hence difficult to design error-handling for.
Did I miss something? Is there an easy workaround? A best practice to propose?
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048394#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...