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#4048394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4048394 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
