Client/server resynchronization with OTMA

In order to guarantee that client transactions are processed and that they are processed only once, OTMA provides a protocol for synchronizing transactions.

Using a synchronized commit-then-send (Commit Mode 0) transaction pipe, the client and IMS can regain message flow in the event of a client or IMS outage. Resynchronization occurs when either IMS or the client terminates normally or abnormally.

Transaction resynchronization achieves the following:
  • Prevents data from being reprocessed
  • Detects that data has not been received and causes the client to resend the data
  • Detects that resynchronization might not be possible
  • Allows the client to decide what actions to take in order to resynchronize
OTMA resynchronization is not symmetrical, and a system's behavior depends on its role: client or IMS. Resynchronization also does not maintain symmetry for send- or receive-sequence numbers. For example, the differences for the input and output sides of an IMS flow are:
Input
IMS logs the client sequence numbers when the transaction is enqueued, and from that moment, the client has no control over dequeuing the transaction.
Output
The application output is enqueued to a synchronized transaction pipe, but the output sequence numbers are not logged at that time. Only after sending the output and receiving an acknowledgment from the client does IMS finally dequeue the message and log the incremented sequence numbers.
All output using a synchronized transaction pipe is sequenced. The second output message is not sent until the ACK message from the client is received for the first output message.

Q:  Why would I use a synchronized tpipe versus a nonsynchronized tpipe?

A:  Use a synchronized tpipe to ensure that client transactions are processed only once in the case of a client or IMS failure. Therefore, synchronized tpipes ensure better transaction recoverability. However, in order to guarantee transaction recovery, you are required to implement resynchronization logic with synchronized tpipes.

Use a nonsynchronized tpipe when the recoverability of a transaction is less of a concern. For nonsynchronized tpipes, the client does not require the resynchronization logic.