Contexts

Contexts allow EPL applications to organize work into threads that the correlator can concurrently execute. In EPL, context is a reference data 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 enqueue 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.

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. A value of true lets the context receive external events; this is a public context. A value of false indicates a private context that cannot receive external events. This is the default.

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 enqueue 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 enqueue . . . 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.

The engine_send utility sends events to all contexts that have been set to receive external events.

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 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.