[TIBCO.EMS .NET client library 7.0 documentation]

A Connection object is a client's active connection to TIBCO EMS Server.

Namespace:  TIBCO.EMS
Assembly:  TIBCO.EMS (in TIBCO.EMS.dll)

Syntax

public class Connection
Public Class Connection
public ref class Connection

Remarks

Connections support concurrent use.

A connection serves several purposes:

  • It encapsulates an open connection with a TIBCO EMS Server. It typically represents an open TCP/IP socket between a client and the TIBCO EMS Server.
  • Its creation is where client authentication takes place.
  • It can specify a unique client identifier.
  • It provides a ConnectionMetaData object.
  • It supports an optional ExceptionListener object.

Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections.

A client typically creates a connection, one or more sessions, and a number of message producers and consumers. When a connection is created, it is in stopped mode. That means that no messages are being delivered.

It is typical to leave the connection in stopped mode until setup is complete and all message consumers have been created. At that point, the client calls the connection's Start method, and messages begin arriving at the connection's consumers. (Outbound messages flow even before calling Start.) This setup convention minimizes any client confusion that may result from asynchronous message delivery while the client is still in the process of setting itself up.

A connection can be started immediately and the setup can be done afterwards. Clients that do this must be prepared to handle asynchronous message delivery while they are still in the process of setting up.

A message producer can send messages while a connection is stopped

Asynchronous Exceptions

When a program uses a connection to send messages, the send calls can detect problems with the connection, and notify the client program (synchronously) by throwing exceptions.

However, when a program uses a connection only to receive messages, the client cannot catch such exceptions. Instead, programs can handle such exceptions asynchronously in one of two idioms. Programmers may select either idiom—but not both (which would cause duplicate exception processing, with undefined behavior).

  • ExceptionHandler events detect this type of problem in a .NET programming idiom.
  • In contrast, the ExceptionListener property mimics the way in which JMS provides similar functionality in a Java programming idiom.
Note: The EMS .NET API does not support the optional methods createConnectionConsumer and createDurableConnectionConsumer.

Inheritance Hierarchy

See Also