A context is an active object that initializes and manages its own thread. The life cycle of the owned thread is bound to the life cycle of the context. A context-owned thread drives I/O and notification events of registered delegates of the context.
All callbacks (or delegate invocation) from the API to the application, message receive callbacks, event callback, and timer callbacks, run from the context thread. Additionally the context thread must run to detect relief from flow control and unblock waiting application threads. The context thread must run to complete the session connection sequence and unblock applications waiting for connection complete. The context thread must run to unblock applications waiting for confirmation on subscription requests. Consequently, applications must not block in callback/delegate routines. Waiting in callback routines can deadlock the application or at a minimum severely degrade receive performance. Deferring SolClient processing by running for excessively long periods of time in the callback routines prevents the API from unblocking other application threads that might be waiting for confirmation of sent messages, or blocked in flow control situations.
The API typically detects when the application has re-entered the API from a callback and will never block. Consequently applications can expect to see SOLCLIENT_WOULD_BLOCK return codes when making API calls from a callback routine, even if the function call would be blocking in other threads. Generally if a function could block because of TCP flow control, SOLCLIENT_WOULD_BLOCK is returned when that function is called from a callback, irrespective of the session property SendBlocking. Further if the application explicitly sets WaitForConfirm on a subscription method (subscribe or unsubscribe) API call made from a callback routine, that function call will return SOLCLIENT_FAIL and set the subcode to ParamConflictImportant: Disposing a context must not be performed in a context callback delegate for the context being disposed. This includes all sessions(ISession), flows(IFlow) and timers (TimerTask) on the context.
Context instances are created through a factory method in ContextFactory. A context has the following responsibilities: Initialization and management of the context-owned thread. Factory and container of session instances. Note that IContext instances can only be created by the ContextFactory.public interface IContext : IDisposable
Properties | Returns a read-only copy of the ContextProperties used to create this session. |
Sessions | Returns a read-only snapshot of the current active (not yet disposed) sessions created within this context. |
CreateSession |
Creates a session instance.
Session properties to customize the session, and message receive and the session
event delegates must be provided for the session. The message receive delegate is
invoked for each received message on this session. The session event delegate is
invoked when session events occur, such as the session going up or down. Both
delegates are invoked in the context of the context thread to which this session belongs.
Note: disposing the corresponding context (IContext) or any of its contained context timers (TimerTask), sessions (ISession) or flows (IFlow) must not be performed from within the registered delegates (messageEventHandler or sessionEventHandler). |
Dispose | Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources. (Inherited from IDisposable) |
Start |
Starts the context if it is not already started or disposed.
Obsolete. |
Stop |
Stops the context if it is not already stopped or disposed.
Obsolete. |