3 Event Management Policies

The rule class properties you specify at the time you create the rule class include the event management policies that the Rules Manager should enforce for each rules application. In the case of rules defined for composite event structures, the primitive events are added to the system one at a time. These events are later combined with other primitive events to form composite events that match one or more rule conditions. Depending on the join conditions between primitive events, a primitive event can participate in a 1 to 1, 1 to N, or N-to-M relationship with other events to form one or more composite events. Rules Manager supports application-specific requirements for reusing primitive events and for handling duplicate composite events using rule event management policies and they are broadly classified as follows:

Consumption — determines if an event can be used for multiple rule executions or a single rule execution
Conflict resolution or ordering — determines the order in which matching rules with various events are to be executed
Duration — determines the lifetime of unconsumed primitive events
Auto-commit — determines if each interaction with a rule class should be committed automatically
Storage — determines the storage characteristics of the rule class in the database
Equal — specifies the common equality join predicates for all the rules in a rule class, that is, what are the lists of primitive event attributes that are equal in the composite events configured for a rule class
DML Events — specifies when you create an event structure with one or more table alias attributes, that you can configure the corresponding rule class to consider the DML operation (INSERT, UPDATE, DELETE) on the corresponding tables as the events for which the rules are evaluated. The DML Events specification uses DML events from uncommitted transactions to process the rules. Whereas, in the case of continuous query notification (formerly database change notification) (CNF) events (see Section 2.5 and Section 3.7 for more information), the rules are processed for the DML operations within a transaction after the transaction commit operation.

The event management policies duration and equal are only applicable to rule classes configured for composite events. All other policies are applicable to rule classes configured for simple events as well as rule classes configured for composite events. In addition to the event management policies, the rule class properties allow the specifications for collection of events. A collection specification enables a primitive event to be used in rule conditions involving collections of events as opposed to individual events. For such events, rule conditions can compute aggregate values over a finite but potentially large number of primitive events of the same type and specify predicates on the resulting aggregates. Primitive events of a specific type are grouped based on certain event attributes and aggregate operators, such as SUM, AVG, MIN, MAX, and COUNT on the other event attributes are used to apply predicates.

The rule class properties are all specified in an XML properties document, which is used as one of the arguments (rlcls_prop) to the rule class creation procedure (dbms_rlmgr.create_rule_class). Section 4.8 discusses the rule class property for enabling collections. All other rule class properties are described in the sections that follow.

3.1 Consumption of Events

A primitive event used to form a composite event can be combined with other primitive events to form a different composite event. For example, you can combine two instances of the AddFlight event with one instance of AddRentalCar event to form two different composite events (that could match two different rules). Some rule applications require that once a primitive event matches a rule on its own or in combination with other primitive events, it should not be used with any more rule executions. This implies that a primitive event used to form a composite event is consumed or removed from the system. The consumption property for a rule class determines the policy regarding the reuse of primitive events in the system. The consumption policy is applicable to both the rules defined for simple events and the rules defined for composite events. Two modes of event consumption are possible:

EXCLUSIVE — when the consumption mode is EXCLUSIVE, a primitive event can be used to match only one rule (which ever matches first). Once the corresponding rule action is executed, this event is removed from the system, irrespective of the event duration specification (TRANSACTION, SESSION, or Elapsed time).
SHARED — when the consumption mode is SHARED, a primitive event can be used to match any number of rules and execute their actions. The primitive event is removed from the system only when its duration specification is met. The default consumption policy for a rule class created with no consumption property is SHARED.

Following the same example used previously, if two AddFlight events are already added to the system, the next AddRentalCar event could form two composite events that could match two or more rules. If the rule class is configured for EXCLUSIVE consumption of events, only one of the rule actions can be executed using one of the composite events. This rule can be chosen deterministically if appropriate conflict resolution techniques are employed (see Section 3.2).

The EXCLUSIVE consumption policy for a rule class created for a simple event structure implies that, at most, one rule is executed for any event instance passed to the dbms_rlmgr.process_rules procedure. If the event matches more than one rule, the rule that is chosen for execution is determined using the ordering property of the rule class (see Section 3.2 that describes ordering). You can configure the rule class created for a primitive event structure with the EXCLUSIVE event consumption policy using the following XML properties document (as the rlcls_prop argument to the dbms_rlmgr.create_rule_class procedure).

<simple consumption="exclusive"/>

Other valid forms of consumption specification within the rule class properties include the following:

<composite consumption="exclusive"/>

<composite consumption="shared"/>

Rule applications can have different policies regarding the reuse of primitive events for a subset of primitive events used in a composite event. For such applications, the consumption policy can be specified for each primitive event type as a child element of the <composite> element, such as the following:

<composite consumption="shared">
   <object type="AddFlight" consumption="shared">
   <object type="AddRentalCar" consumption="exclusive">
</composite>

The value for the consumption attribute of the <composite> element is used as the default value for all the primitive events in the composite event. This default value is overridden for a primitive event type by specifying it as the child element of the <composite> element and specifying the consumption attribute for this element.

Specifying Custom Logic for Event Consumption

In addition to EXCLUSIVE and SHARED consumption policies, a rule class for composite events can be configured with a RULE consumption policy, which allows individual rules in the rule class to use some custom logic for event consumption. The RULE consumption policy can only be specified at the composite event level and when specified, the consumption policy for the primitive event type cannot be set to EXCLUSIVE. When you configure the rule class for RULE consumption policy, the action callback procedure and the rule class results view are created to return the identifiers for the individual primitive events matching a rule. You use these identifiers to selectively consume some or all of the primitive events atomically. See the DBMS_RLMGR.CONSUME_PRIM_EVENTS function for more information.

3.2 Ordering of Rule Execution

When an event matches a rule on its own or in combination with other primitive events, by default, the order of rule (action) executions is not deterministic. Some rule applications may need the matching rules to execute in a particular order, which is determined by some conflict resolution criteria. Additionally, in the case of exclusive consumption of events, only one of the matching rules is executed. Unless some conflict resolution criterion is specified, this rule is chosen randomly. One of the common techniques of conflict resolution is to order the resulting composite events and matching rules based on the event attribute values and the rule action preferences.

Conflict resolution among composite events

The composite events resulting from the addition of a primitive event can be ordered based on the attributes of the corresponding primitive events. For example, the travel services application may decide to resolve among a set of composite events, consisting of AddFlight and AddRentalCar primitive events, based on the primitive event creation times. So, the conflict resolution criterion for this composite event structure is represented as [Flt.rlm$CrtTime, Car.rlm$CrtTime], implying that an event with earliest creation time is consumed before the others. This notation is similar to that of an ORDER BY clause in a SQL query. Optionally, the DESC keyword can be used with some of the attributes to sort the events in descending order (see information later in this section for complete syntax). When the rule class is configured for exclusive consumption of events, only the top-most event in this sorted list is chosen for rule execution.
Conflict resolution among matching rules for simple and composite events

A composite or a simple event can match one or more rules in a rule class. If more than one rule is matched, by default, their actions are executed in a non-deterministic order. If the order of the rule action executions is important, you can use the rule identifiers and the action preferences associated with the rules to sort the matching rules. For example, the travel services application can resolve among matching rules by using the conflict resolution criterion – [rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid]. In this case, sorting the matching rules is done in ascending order and ordered first by the action preference PromoType, then by the action preference OfferedBy, then by the rule identifier rlm$ruleid. As shown in this example, the rule identifier rlm$rule is used to refer to any rule-specific attribute. The notation and semantics used for specifying conflict resolution criteria are similar to that of an ORDER BY clause in a SQL query. Optionally, you can use the DESC keyword with some of the attributes to sort the rules in the descending order (see information later in this section for complete syntax). When you configure the rule class for exclusive consumption of events, only the top-most rule in the sorted list is chosen for execution.

When a set of composite events matches a set of rules, the exact order of rule executions can be specified by combining the conflict resolution criterion for the composite events with that of the matching rules. The syntax for specifying the conflict resolution criteria is described using the ORDERING property.

The ORDERING property of the rule class determines the order in which a set of rules that match a set of composite events or a simple event are executed. When the consumption policy for a composite event type or for some primitive event types is set to EXCLUSIVE, the ORDERING property also determines the subset of rules that are executed. (The rest of the matching rules are ignored, because the exclusive events that are required to execute the rules are deleted after the first rule execution). The ORDERING property is applicable to both the rules defined for simple events and the rules defined for composite events.

In the case of a rule class created for a composite event structure, the addition of a primitive event to the system could form multiple composite events that could match multiple rules. So, you can specify the ordering of the resulting events and the matching rules using the attributes in the events, the action preferences associated with the rules, and the rule identifiers. For the travel services rule class example, you can specify the ordering of the events and the matching rules as follows:

<composite ordering="Flt.rlm$CrtTime, Car.rlm$CrtTime, rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid"/>

In this ascending column, attribute ranked, ordering specification, you use the rule identifier rlm$rule to refer to the attributes associated with the rule class (action preferences PromoType and OfferedBy and the rule identifier rlm$ruleid); and you use the variables declared for the primitive events in the composite event structure (Flt for AddFlight and Car for AddRentalCar) to access the primitive events' attribute values.

The ORDERING property can be combined with some other policies, such as consumption and duration. Other valid forms of ordering specification within the rule class properties include:

<composite consumption="exclusive"
           ordering="Flt.rlm$CrtTime, rlm$rule.PromoType,
                                      rlm$rule.rlm$ruleid DESC"/>
<simple ordering="rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid/>

In the case of a rule class created for a simple event structure, as there is only one event at any point in time, the ordering is only based on the matched rules. So Rules Manager only allows in the ordering clause, the rule identifier and action preferences associated with the rules.

3.3 Duration of Events

It is common for applications to generate events that will never trigger a rule firing, thus never consuming these events. The duration policy for primitive events determines the maximum lifetime of the events. When you add a primitive event to Rules Manager for incremental evaluation of rules, the event and the evaluation results are stored in the database. These events are later combined with other matching primitive events to form a composite event that conclusively satisfies one or more rule conditions. However, there may not be a matching event to form a composite event. For example, the travel services rule discussed in Section 2.6 may detect an AddFlight event for a rule, but the corresponding AddRentalCar event may not occur (or the AddRentalCar event occurring may not be for a luxury car). So, the duration (or the life) of the primitive events should be set such that the incomplete (composite) events and the results from the incremental rule evaluations are deleted after a certain period.

The duration of a primitive event depends on the rule application and it can be classified into one of following four scenarios.

TRANSACTION: In this scenario, the primitive events added to the system during a database transaction are preserved until the end of the transaction (COMMIT or ROLLBACK). So, a rule for the composite event evaluates to true only if Rules Manager detects all the required primitive events within a database transaction.
SESSION: In this scenario, the primitive events added during a database session are preserved until the end of the session (CONNECT or DISCONNECT). So, a rule for the composite event evaluates to true only if Rules Manager detects all the required primitive events within a database session.
CALL: In some rule applications, a subset of primitive events are truly transient in that an event is considered for a possible match with the rules only at the instance at which the event is added. Such events do not contribute to the event history and they are not considered for any future rule matches. Hence, these events are said to be valid only for the duration of the call (PROCESS_RULES or ADD_EVENT) that processes the rules. You can configure a subset of primitive events within a composite event for the CALL duration. A CALL duration event contributes to a rule execution only if the event, in combination with other events in the system, evaluates a rule condition to true at the time of the call. Such events are not considered for rule matches after the call regardless of any rule executions during the call.
Elapsed time: In this scenario, the duration of a primitive event added to the system is determined by an event timeout associated with the rule class. You specify the event timeout as elapsed time (for example 10 hours, 3 days) and this is added to the creation time (determined by its rlm$CrtTime attribute) to determine the exact time of event deletion.

The duration policy dictates the life span of the primitive events in the system. In the case of a rule class created for simple events, Rules Manager does not store the events in the system (as the rules are evaluated conclusively for each event). So, the duration policy is applicable only for the rule classes created for composite event structures. A rule class configured to reset all the primitive events at the end of each (database) transaction uses the following XML properties document:

<composite duration="transaction"/>

While specifying the duration as elapsed time, the value for the duration attribute can be specified in {[int] minutes | hours | days} format, such as shown here:

<composite duration="20 minutes"/>
<composite duration="2 hours"/>
<composite duration="10 days"/>

These specifications apply to all the primitive events that constitute the composite event. If different duration specifications are required for some primitive event types, you can specify them as child elements of the <composite> element, such as shown here:

<composite duration="10 days">
   <object type="AddFlight" duration="3 days"/>
   <object type="AddRentalCar" duration="call"/>
</composite>

In this case, you use the value of 10 days for the duration attribute of the <composite> element as the default value for all the primitive events in the composite event. This default value is overridden for a primitive event type by specifying it as the child element of the <composite> element and specifying the duration attribute for this element, for example, as shown by the duration property call specified for the AddRentalCar event type. So these AddRentalCar events would be discarded if they did not match a rule during either a PROCESS_RULES or ADD_EVENT call.

A restriction on the duration policy is that the TRANSACTION or SESSION values for the duration policy can only be specified at the composite event level. When specified, these values cannot be overridden at the primitive events level.

3.4 Equality

In the case of a rule class for composite events, identifying the most-common equality join predicates in all rule conditions and specifying those using the EQUAL rule class property is important for performance. All rules in a rule class use one or more common (equality) join predicates to relate the primitive events that form a composite event with each other. You define these join predicates using the attributes of the corresponding primitive event types. For example, in the travel services application, the AddFlight and AddRentalCar events in a composite event are related through the customer identifiers in these primitive events (Flt.CustId = Car.CustId). You can configure the rule class to optimize a limited number of distinct equality join predicates used in its rule conditions using the EQUAL property.

Note:

Use of the EQUAL property at the rule class level is mandatory for better performance.

The EQUAL property used for a rule class may be of two types depending on the homogeneity of the join conditions in its rules. In the case of a rule class with a homogenous set of rules using the same equality join predicate for all its rule conditions, the equal specification for the rule class can be uniquely identified and there is only a single equal specification. On the other hand, when different subsets of rules use different join predicates, you can configure the rule class with a limited number of alternate equal specifications. Each equal specification may be based on a single attribute from each contributing primitive event or it could be based on multiple attributes from each primitive event (concatenated keys) as discussed in this section.

3.4.1 Single Equal Specification for a Rule Class

A single equal specification for a rule class identifies the equality join predicates that are used by all rules in the rule class. For example, if all the rules in the travel services applications relate the primitive events based on the customer identifiers (Flt.CustId = Car.CustId), then you can configure this join predicate as a single equal specification for the rule class's EQUAL property.

In this case, you specify the EQUAL property as a comma-delimited list of attributes, one from each primitive event structure configured for the rule class and it is used as the join predicate for all the rules in the rule class. This list identifies the primitive event attributes that must be equal to form a composite event. For example:

<composite equal="Flt.CustId, Car.CustId"/>

When the composite event has more than two primitive events, the corresponding rule conditions may employ conjunctions of two of more equality join predicates. For example, if reading1, reading2, and reading3 are three primitive events representing RFID readings, the join condition in a rule relating these three events could be reading1.ReaderId = reading2.ReaderId and reading2.ReaderId = reading3.readingId (to check for all three readings to occur at the same reader). The corresponding equal specification is a comma-delimited list of attributes from each primitive event (reading1.readerId, reading2.readerId, reading3.readerId).

In the case of single equal specification, since each rule condition is guaranteed to use the same equality join predicate, the equal specification in the rule class properties obviate the need for the same join predicate in each rule condition. Hence, the rules in the rule class may skip the equality join predicates involving the same set of attributes, as demonstrated with the following examples.

The following rule condition explicitly specifies the equality join predicate in conjunction with other (possible inequality) join predicates. This specification uses the SQL WHERE clause syntax for join predicates.

<condition>
  <and join="Flt.CustId = Car.CustId and Car.rlm$CrtTime > Flt.rlm$CrtTime ">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object> CarType = 'Luxury' </object>
  </and>
</condition>

The following rule condition demonstrates the use of the EQUAL clause in the place of the equality join predicate in the previous example. The EQUAL clause specification for a rule condition acts as a short representation of equality join predicates especially when the rule condition has negation (see Section 5.3) or Any n (see Section 5.5) constructs.

<condition>
  <and equal="Flt.CustId, Car.CustId"  
       join="Car.rlm$CrtTime > Flt.rlm$CrtTime">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object> CarType = 'Luxury' </object>
  </and>
</condition>

When the EQUAL property for the rule class is specified as equal="Flt.CustId, Car.CustId", use of the corresponding join predicate or the EQUAL clause in a rule condition (as shown with the previous two examples) is redundant. In this case, the single equal specification associated with the rule class is enforced for all rules in the rule class. Hence, the following rule condition is equivalent to the previous two examples when the rule class is created with the previous EQUAL property.

<condition>
  <and join="Car.rlm$CrtTime > Flt.rlm$CrtTime">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object name="Car"> CarType = 'Luxury' </object>
  </and>
</condition>

Equal Specification with Concatenated Keys

Often the equality join predicates between primitive events may involve more than one attribute from each primitive event. For example, in the travel services application, the AddFlight and AddRentalCar events may be related to each other based on their itineraries (equality predicate on Depart and CheckOut dates from respective events), in addition to the equality of the customer identifiers. A sample rule using such join predicates is as follows.

<and join="Flt.CustId = Car.CustId and Flt.Depart = Car.CheckOut"> 
       <object name="Flt"> Airline = 'Abcair' and ToCity = 'Orlando' </object> 
       <object name="Car"> CarType = 'Luxury' </object>
    </and>

If the equality predicates involving multiple attributes from each primitive event are common across all the rules in the rule class, you can configure the rule class with an EQUAL property specification with concatenated keys for optimal performance.

<composite equal="(Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)"/>

Note:

A maximum of three key concatenations can be specified with the rule class's EQUAL property.

With the previous specification, the combination of [Flt.CustId, Flt.Depart] attributes acts as a concatenated key for each Flt event and it should match the concatenated key from a Car event for any rule in the rule class to be true. Since you enforce the previous equal specification for all rules in the rule class, a similar equal specification for each rule may be skipped.

3.4.2 Alternate Equal Specifications

Another form of EQUAL property specification for a rule class identifies a list of the most common equality join predicates in its rules. For this purpose, each single equal specification is grouped using parentheses and alternate equal specifications are separated using a vertical bar ( '|') character. For example, if you create a rule class with two primitive events of the same RFIDRead type, a subset of rules in the rule class may join the primitive events on their ItemId attributes (reading1.ItemId = reading2.ItemId). Another subset of the rules in the same rule class may relate the primitive events on their ReaderId attributes (reading1.ReaderId = reading2.ReaderId). You can optimize the rule class to process both types of these rules efficiently using the following EQUAL property:

<composite equal="(reading1.ItemId, reading2.ItemId) |
                  (reading1.ReaderId, reading2.ReaderId)"/>

Note:

At most, you can define five alternate equal specifications for a rule class's EQUAL property.

The alternate equal specifications provide a means for optimizing the rule evaluation for the most common join predicates in a rule class and the rule class does not automatically enforce any equality join predicates for its rules. For optimal performance, each rule condition in the rule class must specify one of the alternate equal specifications for its EQUAL clause. For example, the following rule's EQUAL clause matches one of the alternate equal specifications at the rule class level and hence, this rule is optimized:

<condition>
  <and equal="reading1.ItemId, reading2.ItemId"/>
    <object name="reading1"/>
    <object name="reading2"/>
  </and>
</condition>

Hence, the EQUAL clause for individual rules in a rule class not only acts as a short representation for the equality join predicate, but also helps map it into one of the alternate EQUAL property specifications.

The alternate equal specification may include one or more specifications involving concatenated keys. For example, if the travel services application uses some rules, which just relate the AddFlight and AddRentalCar events based on their customer identifiers and some other rules on the identifiers as well as the dates in their itineraries, you can configure the rule class with the following equal property for optimal performance.

<composite equal="(Flt.CustId, Car.CustId)  | 
                       (Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)"/>

With this specification at the rule class level, individual rules in the rule class may use either of these two alternate EQUAL property specifications.

<condition>
  <and equal="(Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object> CarType = 'Luxury' </object>
  </and>
</condition>

Note that while matching an EQUAL clause specified for a rule with one of the alternate equal specifications, the order of attributes is irrelevant.

3.5 Storage Properties

Use the STORAGE attribute of the <simple> or <composite> element to specify the storage properties for the rule class table and the internal objects created for the rule class. By default, the database objects used to manage the rules in a rule class are created using user defaults for the storage properties (Example: tablespace specification). The value assigned for this attribute can be any valid storage properties that you can specify in a typical SQL CREATE TABLE statement. The following XML properties document shows how to use it (as the argument to the dbms_rlmgr.create_rule_class procedure) to create a rule class for simple events that resides in a tablespace TBS_1 and uses exclusive consumption policy:

<simple storage="tablespace TBS_1" consumption="exclusive"/>

Another example of specifying storage attributes in the rule class properties is as shown:

<composite storage="tablespace TBS_1"/>

3.6 AUTOCOMMIT

In most cases, all the Rules Manager procedures commit immediately after each add rule, delete rule, and process rule operation. You can configure the rule class to follow transaction boundaries by turning off the auto-commit functionality. For this purpose, you can specify the AUTOCOMMIT property in the rule class properties document. For example:

<simple autocommit="NO"/>

You can specify the AUTOCOMMIT property for the rule class created for simple as well as composite events. Other valid forms of specifying the AUTOCOMMIT property include:

<composite autocommit="NO" consumption="shared"/>
<composite autocommit="YES"/>

When the AUTOCOMMIT property is set to NO, the set of Rules Manager operations (add rule, delete rule, and process rule) performed in a transaction can be rolled back by issuing a ROLLBACK statement. An exception to this rule is when the action callback procedure (implemented by the end user) performs an irreversible operation (sending a mail, performing a data definition language (DDL) operation, commit, rollback, and so forth). A DDL operation within an action callback operation automatically commits all the operations performed in that transaction. To avoid this situation, you should perform any DDL operations in an autonomous transaction.

Turning off the AUTOCOMMIT property for a rule class can limit the concurrent operations on the rule class. This is especially the case when you create the rule class for composite events that is configured for exclusive consumption policy. (In a transaction, the consumed events are locked until the transaction is committed and the other sessions may wait for these events to be released.)

The default value for the AUTOCOMMIT property is dependent on other event management policies (see Table 3-1). The default value for this policy is NO for a rule class configured for simple (non-composite) rules and a composite rule class configured with the SESSION or TRANSACTION duration policy. (These configurations do not pose issues with sharing of events across sessions). For all other configurations, a default value of YES is used for the AUTOCOMMIT property. Note that the AUTOCOMMIT property cannot be set to YES when the duration policy is set to TRANSACTION. Also, the AUTOCOMMIT property cannot be set to NO when one or more primitive event types are configured for EXCLUSIVE or RULE consumption policy.

When you define the event structure with one or more table alias constructs and you configure the corresponding rule class for DML events (see Section 3.7), the AUTOCOMMIT property is always set to NO. Note that this could result in deadlocks while working with EXCLUSIVE or RULE consumption policies.

A rule class with the AUTOCOMMIT property set to NO cannot contain rules involving negation and a deadline (See Section 5.3).

3.7 DML and CNF Events

When you create an event structure with one or more table alias attributes (see Section 4.1), then you can configure the corresponding rule class to consider the SQL INSERT and SQL*Loader operations on the corresponding tables as the events for which the rules are evaluated. You can enable this rule class behavior using the DMLEVENTS or CNFEVENTS property for the rule class:

<simple dmlevents="I"/>
<simple cnfevents="I"/>

You can specify either of these properties for a rule class configured for simple and composite events. Events for UPDATE and DELETE operations on the underlying tables are only applicable for the rule classes configured for composite events.

<composite dmlevents="IUD"/>
<composite cnfevents="IUD"/>

When a row in a table is deleted, the state information for the rules matching this row are marked for deletion. Similarly, when the row is updated, the existing state information is marked for deletion and the new state information is computed for the updated row. The deleted row (or the old image of the updated row) does not have an effect on the past rule states. That is, the delete operation does not cause existing rule states to automatically become true due to the retraction of the event. This scenario pertains to the rule conditions with negative constructs, in which the event matched the negative portion of the rule before it is deleted.

With the DMLEVENTS specification, Rules Manager uses the events generated from a DML operation to process the rules in the rule class as part of the same DML command. This is achieved with the use of row level triggers on the underlying tables. On the other hand, when you use the CNFEVENTS specification, the rules are processed after the commit of the DML transaction using the net data changes (within the transaction) as the events. In effect, if a row is inserted into a table and then updated within the same transaction, with the CNFEVENTS specification, the rules are processed once for the newly inserted row (with committed data). Whereas, when you use the DMLEVENTS specification, the rules are processed twice for the same row - once synchronously with the INSERT operation and again with the UPDATE operation. See Section 4.7 for additional information on the use of CNFEVENTS.

When you specify the DMLEVENTS policy, the AUTOCOMMIT policy for the rule class should be NO. In this case, the AUTOCOMMIT policy of NO is allowed even when the consumption policy is set to EXCLUSIVE or RULE (which is considered an invalid combination when the DMLEVENTS policy is not used). Note that the use of the EXCLUSIVE or RULE consumption policy with the DMLEVENTS policy could result in application deadlocks.

3.8 Rule Class Property Dependencies and Defaults

You can mix and match most of the rule class properties (or event management policies) described in this section while defining a rule class. However, Table 3-1 shows some of the combinations of these properties that are considered invalid. For example, if the rule classes' AUTOCOMMIT property is set to YES, setting the DURATION policy to TRANSACTION is invalid. This is because the events are deleted from the system as soon as they are added and they cannot be combined with other events to form composite events. The DMLEVENTS policy has no direct influence on the valid and invalid combination of event management policies. This policy only effects the default value for the AUTOCOMMIT policy.

Table 3-1 Valid and Invalid Rule Class Property Combinations

	AUTOCOMMIT	CONSUMPTION	DURATION
Invalid	Yes	--	Transaction
Valid	Yes	--	Session
Valid	Yes	--	[n] Units
Valid	No	Shared	--
Valid	No	Exclusive	Transaction^Foot 1
Valid	No	Exclusive	Session^Footref 1
Invalid	No	Exclusive	[n] Units^Foot 2
Valid	No	Rule^Foot 3	Transaction^Footref 1
Valid	No	Rule	Session^Footref 1
Invalid	No	Rule	[n] Units^Footref 2

^Footnote 1A rule class operating in SESSION or TRANSACTION mode has no concurrency issues across the database session, as each session gets a private copy of the events and incremental results.

^Footnote 2A rule class with the EXCLUSIVE consumption policy locks some rows in order to mark them "consumed" and may not actually consume the rows. Such rows are kept from being consumed by other database sessions and thus result in deadlocks. So, it is recommended that the locked rows be released with AUTOCOMMIT="YES" property.

^Footnote 3RULE is a special form of the EXCLUSIVE consumption policy where the consumption of certain events is initiated by the end-user.

The default values for various event management policies for a rule class configured for simple events are as follows:

CONSUMPTION   :  Shared
DURATION      :  Infinite Duration (NULL)
AUTOCOMMIT    :  No

The default values for the event management policies for a rule class configured for a composite event is sometimes dependent on other event management policies, as follows:

CONSUMPTION   :  Shared
DURATION      :  Infinite Duration (NULL)
AUTOCOMMIT
   IF DMLEVENTS = IUD                                 : NO
   ELSE IF DURATION = TRANSACTION / SESSION           : NO
   ELSE                                               : YES