You inject queries into a running correlator with the Apama macros for Ant, (install_dir\etc\apama-macros.xml) or with Software AG Designer. You can delete queries from a running correlator by performing a delete operation and specifying a query name. You can use the same tools that you use to delete monitors: engine_delete utility, Software AG Designer, Apama macros for Ant (apama-macros.xml), or deleteName() method on the engine client API.

If you are using a cluster of correlators, it is your responsibility to inject each query into each correlator in the cluster, and to delete a query from each correlator in a cluster. This keeps deployed queries in sync across the cluster. In other words, injecting or deleting a query on one host in a cluster does not automatically inject or delete the query on the other cluster members.

Unlike monitors, the lifetime of query instances is either automatic (for non-parameterized queries) or controlled by the Scenario Service (for parameterized queries). There are no spawn or die equivalents in queries, and you cannot use these EPL statements in queries.

When a non-parameterized query is injected, a single instance of the query is automatically created at injection time and it begins processing events. You cannot use the Scenario Service API to edit or delete this single instance or to create new instances. For parameterized queries, after injection, only the query definition is created automatically. The query does not start processing events specified in its inputs section until at least one parameterization is created by means of the Scenario Service. You can control this by using a dashboard or scenario browser. The Scenario Service has methods to create new query instances, edit instances and delete instances.

When using a cluster of correlators, the parameterizations are kept in sync across all members of the cluster. Creating a query instance while connected to one cluster member will create it on all members. The instance can be edited or deleted by any client connected to any member. There may be short delays in replicating parameterization data on each cluster member because this happens asynchronously. However, the recommendation is to edit or delete a particular parameterization from Scenario Service clients that are all connected to the same correlator. This ensures that edit and delete operations are performed in the same order on every cluster member. If you try to edit or delete the same parameterization from different cluster members the results are unpredictable.

If a query executes code in a where clause, aggregate or other expression that results in an exception due to the current values in the window, the query ignores the exception and continues running. For example, an attempt to divide an integer by zero causes an ArithmeticException. If a query experiences an exception that means it cannot continue (such as repeated exceptions while trying to retrieve or store window data), then the query instance will enter the failed state, which will be reported by the Scenario Service. In this case, the query does not process additional events. The correlator log file should contain information that explains why the query failed. The problem that caused the failed state needs to be corrected. After correcting the problem, if the query is a parameterized query, you should delete the failed parameterization and then re-create it. For a non-parameterized query, you must delete and then re-inject the query.

When a query is deleted with the engine_delete utility or equivalent, all instances of the query are terminated and the Scenario Service will reflect that the query definition has been unloaded. The query can be re-injected, if needed. Remember that deletions and injections must be performed on every member in a cluster.

As long as a query is active, the find statement in a query is active for each value of the key that is specified in the query's inputs section. Thus, find A as a in a query is similar to on all A() as a in a monitor. The find statement generates a match set each time the latest event causes a match. If the find statement specifies any aggregates and the every modifier, which can only be used with aggregates, then each new match set causes the find statement to add to the aggregate.

In monitors, listeners can match either the first set of matching events, or specify the all operator to fire for every set of matching events. For example, on A() as a -> B() as b fires on the first A and B events, while on all A() as a -> all B() as b fires for every combination of an A event with a later B event. In a query, find A as a -> B as b fires on every B event after an A event if an A event is still in the window defined in the inputs section. The match set contains the most recent A event and the most recent B event. The following table provides examples. The assumption is that all input events remain in the query's window.