ISession object is a single-threaded context for producing and consuming messages.
Warning: While an
IConnection object supports multi-threaded access, an
ISession object only supports single threaded access and multi-threaded behavior is undefined. If an application requires multiple concurrently active consumers and/or producers, then the application must create multiple sessions. For additional information on multi-threading, read the following paragraphs carefully, also see the WebLogic .NET programmer's guide best practices section for examples of improperly coding applications for thread safety when using sessions and their child messages, consumers, and producers.
A session serves several purposes:
ITopicobjects for those clients that need to dynamically use provider-specific destination names (most applications instead lookup destinations using the IContext JNDI lookup method).
A session can create and service multiple message producers and consumers. Do not multi-thread the session - for example do not call two producers from the same session concurrently - see the Warning note above and read on for more information.
One typical use is to have a thread block on a synchronous
IMessageConsumer until a message arrives. The thread may then use one or more of the
If a client desires to have one thread produce messages while others concurrently consume them, the client must use a separate session for its producing thread.
Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection
It should be easy for most clients to partition their work naturally into sessions. This model allows clients to Start simply and incrementally add message processing complexity as their need for concurrency grows.
Close method is the only session method that can be called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction Rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.
The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.
A transaction is completed using either its session's
Commit method or its session's
Rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done. If a
Commit call throws an ambiguous exception, then the result of the transaction is ambiguous: either all operations within the transaction succeeded, or all operations rolled back.
For a list of all members of this type, see ISession Members.
Assembly: WebLogic.Messaging (in WebLogic.Messaging.dll)