Package com.bloomberglp.blpapi

Class Session

java.lang.Object
com.bloomberglp.blpapi.AbstractSession
com.bloomberglp.blpapi.Session
public class Session extends AbstractSession
This class provides a session for making requests and subscriptions to services

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 when it is constructed. The setEventHandler() method may be called to adjust the way events are handled subsequently and the AbstractSession.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 AbstractSession.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 canceled using AbstractSession.cancel(CorrelationID) or unsubscribe(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 AbstractSession.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().

  • Constructor Details

    • Session

      public Session()
      Same as calling Session(SessionOptions(), null, null

    • Session

      public Session(SessionOptions sessionOptions)
      Create a session with the specified sessionOptions

      Same as calling Session(sessionOptions, null, null)

    • Session

      public Session(SessionOptions sessionOptions, EventHandler handler)
      Create a session with the specified sessionOptions and dispatch events on this session to the specified handler

      Same as calling Session(sessionOptions, handler, null

    • Session

      public Session(SessionOptions sessionOptions, EventHandler eventHandler, EventDispatcher eventDispatcher)
      Create a session with the specified sessionOptions and dispatch events on this session using the provided dispatcher to the specified handler

      See SessionOptions for information on what options can be specified

      If the specified eventHandler is not null then this Session will operate in asynchronous mode, otherwise the Session will operate in Synchronous mode.

      If eventDispatcher is null then the Session will create a default EventDispatcher for this Session which will use a single thread for dispatching events. For more control over event dispatching a specific instance of EventDispatcher can be supplied. This can be used to share a single EventDispatcher among multiple Session objects

      If an eventDispatcher is supplied which uses more than one thread the Session will ensure that events which should be ordered are passed to callbacks in a correct order. For example, updates to a single subscription

      Each EventDispatcher uses it's own thread or pool of threads so if you want to ensure that a session which receives very large messages and takes a long time to process them does not delay a session that receives small messages and processes each one very quickly then give each one a separate EventDispatcher.

      Parameters:
      sessionOptions - values in SessionOptions are used for configuring this session
      eventHandler - the event handler to which all events are delivered
      eventDispatcher - The dispatcher to be used for dispatching events.

  • Method Details