Session modes available for ISession objects. A session's mode is set by the application when the session is created.
| Member Name | Description |
|---|---|
| AUTO_ACKNOWLEDGE | With 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_ACKNOWLEDGE | With 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_ACKNOWLEDGE | This 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 |
| SESSION_TRANSACTED | With 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)
WebLogic.Messaging Namespace | CreateSession | ISession | Acknowledge | Recover | Commit | Rollback