| Oracle® Database Rules Manager and Expression Filter Developer's Guide 11g Release 1 (11.1) Part Number B31088-01 |
|
|
View PDF |
| Oracle® Database Rules Manager and Expression Filter Developer's Guide 11g Release 1 (11.1) Part Number B31088-01 |
|
|
View PDF |
The rule class properties specified at the time of creation 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. Application-specific requirements for reusing primitive events and for handling duplicate composite events are supported 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 an event structure is created with one or more table alias attributes, that the corresponding rule class can be configured 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 CNF events, the rules are processed for the DML operations within a transaction after the transaction commit.
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). The rule class property for enabling collections is discussed in Section 4.8. All other rule class properties are described in the sections that follow.
A primitive event used to form a composite event can be combined with other primitive events to form a different composite event. For example, two instances of the AddFlight event can be combined with one instance of AddRentalCar event to form two different composite events (that could match two different rules). In some rule applications, it is required 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). The rule class created for a primitive event structure can be configured 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 the rule class is configured 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. These identifiers can be used to selectively consume some or all of the primitive events atomically. See the DBMS_RLMGR.CONSUME_PRIM_EVENTS procedure for more information.
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 Section 3.2 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, the rule identifiers and the action preferences associated with the rules can be used 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, 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, the DESC keyword can be used with some of the attributes to sort the rules in the descending order (see Section 3.2 for a complete syntax). When the rule class is configured 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, the ordering of the resulting events and the matching rules can be specified using the attributes in the events, the action preferences associated with the rules, and the rule identifiers. For the travel services rule class example, the ordering of the events and the matching rules can be specified 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, rlm$rule is used to refer to the attributes associated with the rule class (action preferences PromoType and OfferedBy and the rule identifier rlm$ruleid) and the variables declared for the primitive events in the composite event structure (Flt for AddFlight and Car for AddRentalCar) are used 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, only the rule identifier and action preferences associated with the rules are allowed in the ordering clause.
It is common for applications to generate events that will never trigger a rule firing, thus these events will never be consumed. The duration policy for primitive events determines the maximum lifetime of the events. When a primitive event is added to the 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 all the required primitive events are detected 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 all the required primitive events are detected 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. A subset of primitive events within a composite event can be configured 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. The event timeout is specified 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, they can be specified 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, the value of 10 days for the duration 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 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.
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. These join predicates are defined 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). The rule class can be configured to optimize a limited number of distinct equality join predicates used in its rule conditions using the EQUAL property.
Note:
Use of theEQUAL 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, the rule class can be configured 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.
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 this join predicate can be configured as a single equal specification for the rule class's EQUAL property.
In this case, the EQUAL property is specified 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, the rule class can be configured 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 the previous equal specification is enforced for all rules in the rule class, a similar equal specification for each rule may be skipped.
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, in a rule class created 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). The rule class can be optimized 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, five alternate equal specifications can be defined for a rule class'sEQUAL 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, the rule class can be configured 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.
The STORAGE attribute of the <simple> or <composite> element is used 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 can be specified in a typical SQL CREATE TABLE statement. The following XML properties document can be used (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"/>
In most cases, all the Rules Manager procedures commit immediately after each add rule, delete rule, and process rule operation. The rule class can be configured to follow transaction boundaries by turning off the auto-commit functionality. For this purpose, the AUTOCOMMIT property can be specified in the rule class properties document. For example:
<simple autocommit="NO"/>
The AUTOCOMMIT property can be specified 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, any DDL operations should be performed 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 the rule class is created 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 the event structure is defined with one or more table alias constructs and the corresponding rule class is configured 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).
When an event structure is created with one or more table alias attributes (see Section 4.1), then the corresponding rule class can be configured to consider the SQL INSERT and SQL*Loader operations on the corresponding tables as the events for which the rules are evaluated. This rule class behavior can be enabled using the DMLEVENTS or CNFEVENTS property for the rule class:
<simple dmlevents="I"/> <simple cnfevents="I"/>
Either of these properties can be specified 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 will be 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, the events generated from a DML operation are used 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 the CNFEVENTS specification is used, 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 the DMLEVENTS specification is used, the rules are processed twice for the same row - once synchronously with the INSERT operation and again with the UPDATE operation. See Section 4.9 for additional information on the use of CNFEVENTS.
When the DMLEVENTS policy is specified, 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.
Most of the rule class properties (or event management policies) described in this section can be mixed and matched while defining a rule class. However, some of the combinations of these properties are considered invalid as shown in Table 3-1. 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 |
TransactionFoot 1 |
|
Valid |
No |
Exclusive |
SessionFootref 1 |
|
Invalid |
No |
Exclusive |
[n] UnitsFoot 2 |
|
Valid |
No |
RuleFoot 3 |
TransactionFootref 1 |
|
Valid |
No |
Rule |
SessionFootref 1 |
|
Invalid |
No |
Rule |
[n] UnitsFootref 2 |
Footnote 1 A 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 2 A 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 3 RULE 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
