Session modes available for ISession objects. A session's mode is set by the application when the session is created.
|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 |
|CLIENT_ACKNOWLEDGE||With this session mode, the client acknowledges a consumed message by calling the message's |
|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 |
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.
Assembly: WebLogic.Messaging (in WebLogic.Messaging.dll)