Session


Class

Declaration

class Session 

Purpose

Main organizing context for message activity.

Remarks

Sessions combine several roles:

Single Thread

The JMS specification restricts programs to use each session within a single thread.

Associated Objects

The same single-thread restriction applies to objects associated with a session—namely, messages, message consumers, durable subscribers, message producers, queue browsers, and temporary destinations (however, static and dynamic destinations are exempt from this restriction).

Corollary

One consequence of this rule is that all the consumers of a session must deliver messages in the same mode—either synchronously or asynchronously.

Asynchronous

In asynchronous delivery, the program registers message handler events or message listeners with the session’s consumer objects. An internal dispatcher thread delivers messages to those event handlers or listeners (in all the session’s consumer objects). No other thread may use the session (nor objects created by the session).

Synchronous

In synchronous delivery, the program explicitly begins a thread for the session. That thread processes inbound messages and produces outbound messages, serializing this activity among the session’s producers and consumers. Methods that request the next message (such as MessageConsumer.Receive) can organize the thread’s activity.

Close

The only exception to the rule restricting session calls to a single thread is the method Session.Close; programs can call Close from any thread at any time.

Transactions

A session has either transaction or non-transaction semantics. When a program specifies transaction semantics, the session object cooperates with the server, and all messages that flow through the session become part of a transaction.

After these actions, both Commit and Rollback immediately begin a new transaction.

(Sheet 1 of 2)

Member
Description
Properties
AcknowledgeMode
int {get;}
This mode governs message acknowledgement and redelivery for consumers associated with the session. For values, see Acknowledge Modes.
This property is irrelevant when IsTransacted is true.
SessionAcknowledgeMode
SessionMode {get;}
This parallel property accesses the same information using enumerated values (instead of ordinary integers). We recommend it over the ordinary integer-valued accessor, because it enables .NET to do stronger type checking at compile time, which can enhance program reliability. For values, see SessionMode .
Connection
Connection {get;}
The session is associated with this connection.
IsClosed
bool {get;}
When true, the session has been closed.
When false, the session is valid.
MessageListener
IMessageListener {get; set;}
This property is deprecated; use the property of MessageConsumer with same name—MessageListener , or MessageHandler .
SessID
long {get;}
Session ID.
IsTransacted
bool {get;}
When true, the session has transaction semantics, and AcknowledgeMode is irrelevant.
When false, it has non-transaction semantics.

(Sheet 1 of 2)

Method
Description
Page
Messages
151
155
156
159
162
Destinations
150
160
161
158
163
Consumers & Producers
152
153
157
167
Transactions
149
165
Other
148
164
166

(Sheet 1 of 2)

Field
Description
SESSION_TRANSACTED
int
The IsTransacted property has this value (true) if the session uses transaction semantics.
Acknowledge Modes
AUTO_ACKNOWLEDGE
int
In this mode, the session automatically acknowledges a message when message processing is finished—that is, in either of these methods returns successfully:
  • synchronous Receive call
  • asynchronous listener handler
CLIENT_ACKNOWLEDGE
int
In this mode, the client program acknowledges receipt by calling Message.Acknowledge . Each call acknowledges all messages received so far.
DUPS_OK_ACKNOWLEDGE
int
As with AUTO_ACKNOWLEDGE, the session automatically acknowledges messages. However, it may do so lazily. Lazy means that the provider client library can delay transferring the acknowledgement to the server until a convenient time; meanwhile the server might redeliver the message. Lazy acknowledgement can reduce session overhead.
EXPLICIT_CLIENT_ACKNOWLEDGE
int
As with CLIENT_ACKNOWLEDGE, the client program acknowledges receipt by calling Message.Acknowledge . However, each call acknowledges only the individual message. The client may acknowledge messages in any order.
This mode and behavior are proprietary extensions, specific to TIBCO EMS.
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
int
In EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode, the client program lazily acknowledges only the individual message, by calling Message.Acknowledge . The client may acknowledge messages in any order.
Lazy means that the provider client library can delay transferring the acknowledgement to the server until a convenient time; meanwhile the server might redeliver the message.
This mode and behavior are proprietary extensions, specific to TIBCO EMS.
NO_ACKNOWLEDGE
int
In NO_ACKNOWLEDGE mode, messages do not require acknowledgement (which reduces message overhead). The server never redelivers messages.
This mode is available for topic sessions only.
This mode and behavior are proprietary extensions, specific to TIBCO EMS.


TIBCO Enterprise Message Service™ .NET Reference
System Release 4.3, February 2006
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com