WebLogic Messaging API Class Library |

# ISession Interface

An `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:

- It is a factory for its message producers and consumers.
- It supplies message factories.
- It provides a way to lookup `IQueue` or `ITopic` objects for those clients that need to dynamically use provider-specific destination names (most applications instead lookup destinations using the IContext JNDI lookup method).
- It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
- It defines a serial order for the messages it consumes and the messages it produces.
- It retains messages it consumes until they have been acknowledged.
- It serializes execution of message listeners registered with its message consumers.

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 `ISession`'s `IMessageProducer`s.

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 `Close` method.

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.

The `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.

public interface ISession

#### Requirements

Namespace: WebLogic.Messaging

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

#### See Also

ISession Members | WebLogic.Messaging Namespace | IConnection.CreateSession | IMessage