WebLogic Messaging API Class Library

Constants.SessionMode Enumeration

Session modes available for ISession objects. A session's mode is set by the application when the session is created.



Member Name Description
AUTO_ACKNOWLEDGEWith this session mode, the session automatically acknowledges a client's receipt of a message either when the session has successfully returned from a call to Receive or when a message listener the session has called to process the message successfully returns and the listener application has not called ISession.Recover().
CLIENT_ACKNOWLEDGEWith this session mode, the client acknowledges a consumed message by calling the message's Acknowledge method. Acknowledging a consumed message acknowledges all messages that the session has consumed.
DUPS_OK_ACKNOWLEDGEThis session mode instructs the session to automatically but lazily Acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should only be used by consumers that can tolerate duplicate messages. Use of this mode can reduce session overhead by minimizing the work the session does to prevent duplicates.
NO_ACKNOWLEDGE With this session mode, no acknowledge is required (similar to the auto and dups_ok modes), but calls to ISession.Recover will not normally force a redelivery as the delivered mesage will already be deleted in all cases. This is a WebLogic extension of the JMS specification.

Messages sent to a NO_ACKNOWLEDGE session are immediately deleted from the server prior to delivery to the client. Messages received in this mode are not recoverable, and as a result messages may be lost if the network or client fails before the client actually receives the message but after the server delivers it.

This mode is supplied for applications that do not require the quality of service provided by the explicit or implicit session acknowledge modes, and that do not want to incur the associated network and latency overhead.

You should avoid using this mode if your application cannot handle lost messages except in some applications that use non-durable topic subscribers. A non-durable topic subscriber will not lose messages in this mode unless it expects messages to be redelivered when the application calls ISession.Recover. Non-durable subscribers are different than other types of consumers in this use case, as by definition non-durable topic subscribers cannot continue to receive messages once they fail -- once a non-durable subscriber fails due to a server crash, unrecoverable network failure, or client crash, all of its messages deleted regardless of acknowledge mode.

SESSION_TRANSACTEDWith this session mode, a session becomes transacted. Messages sent using a transacted session will not become available to consumers until the sending application calls ISession.Commit(); similarly, messages received using a transacted session will not be deleted from the server until the application calls ISession.Commit(). Committing or rolling back a transacted session transaction automatically begins a new transaction. Transacted session transactions are guaranteed to be fully ACID: the send and receive operations that participate in the same transaction will either all commit or will all rollback. If an ISession.Commit() call throws an ambiguous exception, then it is ambiguous whether or not the transaction actually committed or rolled back, but the transaction remains ACID (this is similar to the semantics of an XA transaction).

Note that transacted sessions are not the same as XA sessions, and so do not participate in global XA transactions. Global XA support is not available in the first release of the WebLogic .NET JMS client.


Namespace: WebLogic.Messaging

Assembly: WebLogic.Messaging (in WebLogic.Messaging.dll)

See Also

WebLogic.Messaging Namespace | CreateSession | ISession | Acknowledge | Recover | Commit | Rollback