Query on Transaction Management in MP model

Question

For a transaction in MP model, if one node where the transaction is happening goes down/crashes for some reason, will the transacation continue onto the alternate node ? or it needs to be initiated again ? If it continues on second node, how this is being handled by tuxedo ?

Answer 1

Hi,
Unless a failure can be completely hidden, in general the XA specification indicates that a failure must cause a transaction to be rolled back. This is true in SHM or MP mode. So in MP, if machine SITE1 calls a service on machine SITE2 and that service returns failure for any reason such as the machine died so the caller received an error when blocktime was exceeded, the application code returned an error, the link between the machines failed and wasn't able to be recovered before the blocking time or transaction time expired, or the calling process on SITE 1 (either a client or server) dies before committing the transaction with tpcommit(), the transaction will eventually be rolled back.
Currently Tuxedo doesn't retry any services or transactions. Part of the reason for this is that for non-idempotent services, executing them more than once is a problem. So for example if I create a TRANSFER service as in the Tuxedo bankapp sample application, and I implement that service as:
1) tpbegin()
2) tpcall(withdraw...)
3) tpcall(deposit...)
4) tpcommit()And the call to the deposit service fails, re-executing it might cause twice the amount of money to be deposited into the receiving account. The reason for this is that the caller of deposit when it receives an error, can't be certain whether or not the deposit service actually changed the state of the underlying resource manager (RM) which would likely be a database. The failure in the deposit service might have occurred after the database was changed, but before the reply reached the caller of the deposit service. So in a sense, the caller received a false negative outcome. The only guaranteed safe way to retry a request in this scenario is if we know that executing the service once or more than once leaves the system in the exact same state, i.e., the request is idempotent.
We have considered adding support for idempotent services, but haven't seen much customer demand for it. Can you describe what it is you'd like to see Tuxedo do and why?
Regards,
Todd Little
Oracle Tuxedo Chief Architect
PS There is one scenario where Tuxedo will automatically retry a transaction and service and that is with the TMQFORWARD server. It is a server that is configured to:
1) tpbegin()
2) tpdequeue()
3) tpcall()
4) tpenqueue()
5) tpcommit()In this case TMQFORWARD starts a transaction, takes a message off a queue, calls a service of the same name as the queue, then places the reply on another queue, and then commits the transaction. So in the case of success, an request has been processed from the first queue and the reply placed on the second queue. If a failure occurs, the transaction is rolled back, and TMQFORWARD will try the whole sequence again. Since every involved is part of the transaction, it is safe for TMQFORWARD to try again.