Contexts
Contexts allow EPL applications to organize work into threads that the correlator can concurrently execute.
Note: In monitors, you must implement the use of contexts. In queries, the use of contexts is automatically done for you.
In EPL, context is a reference type. When you create a variable of type context, or an event field of type context, you are actually creating an object that refers to a context. The context might or might not already exist. You can then use the context reference to spawn to the context or send an event to the context. When you spawn to a context, the correlator creates the context if it does not already exist.
When you start a correlator it has a single main context. You can then create additional contexts. A context consists of the following:
One or more monitor instances. Except, the main context exists even if it does not contain any monitor instances.
An event input queue.
Listeners that belong to the contained monitor instances.
The correlator maintains event definitions and monitor definitions outside contexts. This lets all contexts share the same event and monitor definitions.
Instances of the same monitor can exist in multiple contexts. Each monitor instance can belong to only one context.
A context has the following properties:
Name — A string that you specify when you create the context. This name does not need to be unique.
ID — The correlator assigns a unique integer.
receiveInput flag — A Boolean value that indicates whether the context can receive external input events on the default channel, which is the empty string (
"").
A value of true lets the context receive external events on the default channel; this is a public context. A value of true is equivalent to a subscription to the default channel; there is no requirement for a monitor instance in this context to subscribe to the default channel.
A value of false indicates a private context that does not receive external events on the default channel. This is the default.
Note that the main context is public.
Channel subscriptions — A context is subscribed to the union of the channels each of the monitor instances in that context is subscribed to. This is a property of the monitor instances running in a context and is not accessible by means of the context reference object.
You can spawn to other contexts. When the last monitor instance in a context terminates, that context stops doing work and stops consuming resources until you spawn another monitor instance to it.
In a context, when you route an event the event goes to the front of that context’s input queue. You can route events only within a context.
You can send an event to a particular context. When you do this, the event goes to the end of the specified context’s input queue. The correlator processes it after it processes any other events that are already on the context’s input queue. See
The send . . . to statement.
You can use a context as part of the key for a dictionary. You can route an event that contains a context field. You cannot parse a context. Context objects are immutable reference objects.
Upon injection, each monitor’s initial instance runs in the main context. You must explicitly create additional contexts. Conceptually, a context is like a correlator but with the following differences:
All contexts share the same namespace, and thus share all monitor and event definitions that have been injected.
A monitor instance must have a context reference to pass an event to that context.
There is one enqueued events queue for all contexts. When you specify the
enqueue command (not the
enqueue event to context command), the enqueued event goes to the special queue for enqueued events. The correlator then places the event on the input queue of each public context. The correlator ensures that an enqueued event always arrives on the appropriate input queue(s). An
enqueue operation never blocks. However, if the input queue of a context is full and the enqueued events queue gets very large, the result can be an
unbounded memory usage error.
Execution of Java is allowed in only the main context.
The
engine_receive utility receives events from all contexts or it can be configured to receive events from only specified channels.
The
engine_send utility sends events to all public contexts or to the contexts that are subscribed to the channels it is configured to send events on.
For information about creating a context, see
context in
Types.
For a monitor instance to interact with the EPL in another context, the monitor instance must have a reference to that context. A monitor instance can obtain a reference to another context in only the following ways:
By creating the context.
By receiving a context reference, which must be of type
context. A monitor instance can receive this reference by means of a sent, routed or enqueued event, or a spawn operation.
If a monitor instance that creates a context does not send a context reference outside itself, no other context can send events to that context, except by means of correlator plug-ins. This affords some degree of privacy for the context.
A context object (a context reference) does not do anything. It is simply the target of the following:
spawn action_identifier() [( argument_list)] to context_expression; send event_expression to context_expression; You can create any number of contexts. Creating a context just allocates an ID and creates a small object.