[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?

[mark.little@jboss.com]

"timfox" wrote : On a related issue, if the commit succeeds in the JBM resource, but some failure occurs e.g. network failure before the invocation returns to the transaction manager, so the tx mgr gets an exception and thinks the commit failed.
  | 
  | So it retries the commit, but there is no record of the tx in the JBM resource since it committed ok and was removed as far as it was concerned.
  | 
  | How should we deal with this? Should we always return success if a commit comes in for a transction we don't know about? Is this safe?

It's complex ;-)

In order to receive a commit from the TM, the resource obviously had to return VoteCommit during prepare. If the resource subsequently decided to change that decision then we're in the realms of heuristics and the resource has to remember that decision durably and respond appropriately during commit.

Unfortunately just because this resource returns VoteCommit in prepare, doesn't mean that all of the participants in the transaction will do so. It could be told to rollback. In that case, it obviously won't receive a commit message from the TM at any point, so we're alright here.

So if it receives a commit and there's no information in the log, it could return committed, on the assumption that the TM will only be sending commit for participants it remembers were associated with this transaction. Usually a good assumption ;-)

There is one wrinkle in this, which if you're a good resource implementation won't show up anyway: if commit fails and you send back HeuristicMixed/Hazard/Rollback (depending on the failure type) and then cleanup, you would be giving the wrong answer next time commit comes in. However, if a heuristic decision happens, you really should remember that *before* replying to the TM and keep the information around until it is resolved.

BTW, I'm assuming we're talking about the case where there has been a previous prepare call, i.e., in 2PC with NO one-phase commit optimisation.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972303#3972303

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972303