IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

Chapter 13. IMS Connector for Java rerouting and timeout support 261

13.3.2 Rerouting the non-delivered messages

If you let IMS Connector for Java and IMS Connect manage the non-delivered IOPCB

responses in their default way, and you want to retrieve those messages, you need to issue

RESUME TPIPE interactions to the same clientIDs that sent the original transactions. This

can be done in two different ways, depending on the kind of connections you are using:

 Using

shareable connections

You must issue the SYNC_RECEIVE_ASYNCOUTPUT using the same Connection object

that you used to send the original transaction. The clientID for this type of connections is

automatically generated by IMS Connector for Java and is associated with each physical

Connection object.

 Using

dedicated connections

You must issue the SYNC_RECEIVE_ASYNCOUTPUT interaction using whatever

Connection object you want, but you have to specify the same clientID that you used to

send the original transaction.

The two restrictions noticed above can make it impractical to use the same Tpipe you used to

send the original message to retrieve the asynchronous output. The first restriction means

that you should design your application in such a way that the

SYNC_RECEIVE_ASYNCOUTPUT interactions immediately follow the transmission of the

original transactions. One such application designs might use SYNCH_SEND interactions

(that is, SEND ONLY messages) to send the transaction to IMS and get all the output using

SYNC_RECEIVE_ASYNCOUTPUT (that is, RESUME TPIPE). Even in this case, you might

lose messages if the responses are delayed and the pool manager decides to destroy a

Connection instance with pending asynchronous output before the application has the

chance to retrieve it.

However, the second restriction imposes the burden of implementing a serialization algorithm

designed in such a way to avoid collisions (each clientID should be used just by one process

instance or thread), starvation (all clientIDs should be polled for asynchronous output in a

reasonable interval of time), and race conditions.

Starting with IMS Connector for Java Versions 2.2.3, 9.1.0.1, and 9.1.0.2, you can avoid this

problem using the reRoute flag and the optional reRoute destination name. You can set both

the flag and the destination name using the corresponding attribute setters, setReroute() and

setRerouteName(), of the IMSInteractionSpec object, or the Rational Application Developer

or WebSphere Studio Application Developer Integration Edition property sheet, as shown in

Figure 13-1 on page 260.

Restriction: If you are running your application in a managed environment (for

example, under WebSphere Application Server), you cannot be sure if you will again

get an instance of a Connection after you close it. In a managed environment, the

Connection instances are pooled, and the pool manager can decide to destroy a

specific one. In that case, you will not be able to retrieve any asynchronous output

queued under the Tpipe associated with that connection.

Restriction: You must take the appropriate precautions to make sure that one specific

clientID is used by just one application thread or instance at a specific moment of time.

If you are issuing a SYNC_RECEIVE_ASYNCOUTPUT against a clientID that is being

used at the same time to send a transaction to IMS Connect, you will get an exception.