Reconnected Session Objects Automatic Failover for JMS Producers

Recovering from a Server Failure 14-5 failure, then the applications creation of the connection will fail due to a duplicate ClientID. ■ Closed Objects Are Not Refreshed – When the application calls javax.jms.Connection.close, javax.jms.Session.close, etc., that object and it descendents are not refreshed. Similarly, when the JMS client is told its Connection has been administratively destroyed, it is not refreshed. ■ Connection with Registered Exception Listener – If the JMS Connection has an application ExceptionListener registered on it, that ExceptionListeners onException callback will be invoked even if the connection is implicitly refreshed. This notifies the application code of the network disconnect event. The JMS client application code might normally call connection.close in onException; however, if it wants to take advantage of the reconnect feature, it may choose not to call connection.close. The registered ExceptionListener is also migrated transparently to the internally refreshed connection to listen for exceptions on the refreshed connection. ■ Multiple Connections – If there are multiple JMS Connections created off the same ConnectionFactory object, each connection will behave independently of the other connections as far as the reconnect feature is concerned. Each connection will have its own connection status, its own connection retry machinery, etc.

14.1.2.5 Reconnected Session Objects

As described in Section 14.1.2.4, Reconnected Connection Objects, JMS Session objects are refreshed when their associated JMS connection gets refreshed see Step 4 in Example 14–1 and Example 14–2 . Session states, such as acknowledge mode and transaction mode, are preserved across each refresh occurrence. The same session object can be used for calls, like createMessageProducer, after a refresh.

14.1.2.5.1 Special Cases for Reconnected Sessions These sections discuss special cases

that can occur when Sessions are reconnected. ■ Transacted Sessions With Pending Commits or Rollbacks – Similar to non-transacted JMS Sessions, transacted JMS sessions are automatically refreshed. However, if there were send or receive operations on a Session pending a commit or rollback at the time of the network disconnect, then the first commit call after the Session refresh will fail throwing a javax.jms.TransactionRolledBackException. When a JMS Session transaction spans a network refresh, the commit for that transaction cannot vouch for the operations done prior to the refresh as part of that transaction from an application code perspective. After a Session refresh, operations like send or receive will not throw an exception; it is only the first commit after a refresh that will throw an exception. However, the first commit after a Session refresh will not throw an exception if there were no pending transactional operations in that JMS session at the time of the network disconnect. In case of Session.commit throwing the exception, the client application code can simply retry all the operations in the transaction again with the same implicitly refreshed JMS objects. The stale operations before a refresh will not be committed and will not be duplicated. Note: For information on how a consumer connection with a ClientID behaves, see Section 14.1.3.4.3, Consumer Connections with a ClientID for Durable Subscriptions. 14-6 Programming JMS for Oracle WebLogic Server ■ Pending Unacknowledged Messages – If a Session had unacknowledged messages prior to the Session refresh, then the first WLSession.acknowledge call after a refresh throws a weblogic.jms.common.LostServerException. This indicates that the acknowledge call may not have removed messages from the server. As a result, the refreshed Session may receive duplicate messages that were also delivered before the disconnect.

14.1.2.6 Reconnected MessageProducer Objects