Issue: OT exposes a transactional interface: start transaction, commit transaction, rollback transaction. The underlying transport drivers that are abstracted by OT: MQSeries, EMQ and MSMQ all have transactional interfaces as well. They are also XA compliant resources and can participate in a two phase commit coordinated transaction. The transactional interfaces of the transport drivers are wrapped within the OT transactional interface.
The CTS transport is an exception and does not have a transactional interface. It has a request/acknowledge interface. It is also not an XA compliant resource. When a reader wants to read a message off a CTS queue, it makes a request of CTS. When CTS gets this request, it sets a timer. After the reader successfully reads the message, the reader sends CTS an acknowledgement. When CTS receives the acknowledgement, it removes the message from the queue and cancels the timer. OT makes use of this request/acknowledge capability and wraps it in its own transactional interface. So, although CTS does not have a transactional interface, OT makes this transparent by hiding the CTS request/acknowledge interface within the OT transactional interface.
Problem: Process Server expects its transport and database resources to be XA compliant. In the case of CTS, Process Server cannot coordinate a transaction with it and a transaction with the database as a single unit of work. (Process Server writes its state to a runtime database so that it can recover itself.) This means that there is a small possibility that Process Server could read a message off the queue, shut down, and when it recovers, the same message will be sitting on the queue. In other words, there is the small possibility of duplicate messages.
Workaround: If the user is using CTS as a transport, write EDL that detects the duplicate message condition and ignore duplicates.
| Copyright © 2002. Sybase Inc. All rights reserved. |
|
|
