I am not sure I explained my position. The commit I am talking about is in JMS, basically making sure that the reply (in this case) reaches the client in timely fashion.
Corelating that with the process instance persistency, it is a different story. My point doesn't exclude process instance persistency (for later recovery) since the message was sent already if the crash happens after the reply - on resume it will not sent twice. If you want to take care of the client state as well, and persist (by posponing as much as you can the message delivery) their data is a different ballgame. This should be covered by future transaction protocols rather than that (Business Process Protocol, WS Protocol) In my opinion is much more important to allow the user to define its own protocol rather than having him with hands tied. So, I will tather go with the second option - if it is what I think it is. I think that a BPEL implementation should focus on process instance recovery rather than implementing a data consistency protocol. If the reply has been sent and then the BPEL crashed that is ok, upon recovery the BPEL should continue with the next activity. If it was not delivered then upon recovery it needs to be delivered (removed from the queue) and reply activity marked as completed. The current implementation makes the use of events (scope/eventHandlers) almost impossible to use - the client waits endlessly for the initial request to return (with the correlations for example) Regards, AA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3922436#3922436 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3922436 ------------------------------------------------------- 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
