[Design of JBoss jBPM] - Re: Failure handling
by estaub
Bill,
In your original scenario, I'm picturing the rollback as originating in an actionhandler performing a non-JBPM-related action. For these cases, I'm dealing with the transactional difficulties by isolating them in their own transaction. Once this is done, exception handlers should be usable.
You should probably also be aware that JBPM uses recursive execution of the graph. I mean that, when a node actionhandler calls leaveNode() or, less properly, signal(), the downstream execution of subsequent nodes happens within that method call; the execution of later nodes happens within the execution scope of the first actionhandler. This can lead to surprising behavior in error conditions, at least for me. I have a fix for this, but I'm not sure that anyone else believes it's a problem!
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069604#4069604
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069604
19 years
[Design of JBoss jBPM] - Re: Failure handling
by tom.baeyens＠jboss.com
exception handlers indeed don't solve your scenario since you're right that they happen inside of the transaction.
i think this is out of scope for jBPM. the client controls the transaction (either through hibernate in standard java or through JTA in enterprise).
In enterprise environments, you could use a Synchronization, no ?
in the POJO implementation, i have done something similar to process exceptions in asynchronous continuations. There i had to implement the scheme that you mention: in case of exception, rollback the transaction, and then start a new to decrement the retry counter. If it is 0, mark it so that it doesn't keep on executing.
But i didn't give any facility for automatically processing dead messages. But you can see them in the newest console.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069594#4069594
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069594
19 years
[Design of JBoss jBPM] - Re: Knowledge of redelivery
by genman
The redelivery flag is not necessarily a useful thing to have access to.
If the JMS provider restarts, it might actually be false even though the message was in the middle of processing earlier. Or, the redelivery flag might actually be set to true even if your MDB.onMessage() was never reached. This could happen if the inflow adapter loses a connection to the JMS provider on another machine.
The spec also says: "If a client receives a message with the redelivered indicator set, it is likely, but not guaranteed, that this message was delivered to the client earlier but the client did not acknowledge its receipt at that earlier time."
JBoss provides a redelivery count as well (I originally wrote this feature) which is persisted, so is a little more reliable. But I wouldn't rely on this for performing transaction compensations.
If a node needs to take additional action on redelivery, for example, then the best thing is to check every time a message is received that that action was or was not performed.
What might be useful to provide are checkpoints that are persisted (not as the MDB transaction context) that indicate some non-transactional resource was used earlier.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4069470#4069470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4069470
19 years