Sessions manage access to services either by requests and responses or subscriptions. A Session can dispatch events and replies in either a synchronous or asynchronous mode. The mode of a Session is determined when it is constructed and cannot be changed subsequently.

A Session is asynchronous if an EventHandler object is supplied whenit is constructed. The SetEventHandler() method may be called to adjust the way events are handled subsequently and the NextEvent() method may not be called. All incoming events are delivered to the EventHandler(s) supplied on construction or subsequently using SetEventHandler().

A Session is synchronous if an EventHandler object is not supplied when it is constructed. The NextEvent() method must be called to read incoming events and the SetEventHandler() method may not be called. Several methods in Session take a CorrelationID parameter. The application may choose to supply its own CorrelationID values or allow the Session to create values. If the application supplies its own CorrelationID values it must manage their lifetime such that the same value is not reused for more than one operation at a time. The lifetime of a CorrelationID begins when it is supplied in a method invoked on a Session and ends either when it is explicitly cancelled using Cancel(CorrelationID), when a Event.EventType.RESPONSE Event (not a PARTIAL_RESPONSE) containing it is received or when a Event.EventType.SUBSCRIPTION_STATUS Event which indicates that the subscription it refers to has been terminated is received.

When using an asynchronous Session the application must be aware that because the callbacks are generated from another thread they may be processed before the call which generates them has returned. For example, the Event.EventType.SESSION_STATUS Event generated by the StartAsync()()()() may be processed before StartAsync() has returned (even though StartAsync() itself will not block).

This becomes more significant when Session generated CorrelationIds are in use. For example, if a call to Subscribe() which returns a Session generated CorrelationID has not completed before the first Events which contain that CorrelationID arrive the application may not be able to interpret those events correctly. For this reason, it is preferable to use user generated CorrelationIDs when using asynchronous Sessions. This issue does not arise when using a synchronous Session as long as the calls to Subscribe() etc are made on the same thread as the calls to NextEvent().