3 Event Management Policies

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, 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 Chapter3).

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

Conflict Resolution

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

Ordering of Rule Execution

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.

Duration of Events

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 Chapter2 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="session"/>
<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.

Equality

In rule applications using composite events, all the rules defined in a rule class have one or more common (equality) join predicates between two or more or all primitive events (that form a composite event). 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 using a fixed number of distinct equality join predicates for its rules can be optimized by configuring the rule class as discussed in this section.

For a rule class configured for the composite event structure, the EQUAL property identifies either the only equality join predicate that relates multiple primitive events within each composite event, or a list of the most common equality join predicates used in forming each composite event. If there is only one equality join predicate, 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 EQUAL property is specified as a comma separated list of attributes, the rules in the corresponding rule class may skip the equality join predicates involving the same set of attributes. So, for a rule class created with the previous properties document, the following three rule conditions have the same effect:

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

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

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

The last rule condition in the previous example also demonstrates the use of the EQUAL property for individual rules in a rule class. The EQUAL property specification for a rule condition acts as a short representation of the equality join predicate, especially when the rule condition has ANY n or negation constructs. The list of attributes specified for the EQUAL property are converted into appropriate join predicates and appended (as conjunctions) to the join condition of each rule in the rule class.

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 EQUAL property specification is grouped using parenthesis and alternate EQUAL property 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)"/>

The previous syntax for the EQUAL property can be used to specify up to five alternate EQUAL property specifications for a rule class. The alternate EQUAL property specifications provide a means for optimizing the rule evaluation for the most common join predicates in a rule class and it does not automatically use any equality join predicates for its rules. The rules in the rule class are mapped into one of the alternate EQUAL property specifications based on the EQUAL property used for the individual rules. For example, the following rule's EQUAL property specification matches one of the EQUAL property 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 property 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.

Storage Properties

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"/>

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

<composite storage="tablespace TBS_1"/>

AUTOCOMMIT

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 rules 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 rules 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 Chapter3) 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 Chapter4).

DML Events

When an event structure is created with one or more table alias attributes (see Chapter3), 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 property for the rule class:

<simple dmlevents="I"/>

This property can be specified for a rule class configured for simple and composite events. In the current release, UPDATE and DELETE operations on the underlying tables are ignored and only the INSERT operations are recognized as events.

<composite dmlevents="I"/>

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.

Rule Class Property Dependencies and Defaults

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.

^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 = I                                   : NO
   ELSE IF DURATION = TRANSACTION / SESSION           : NO
   ELSE                                               : YES

Rules Specified on Relational Tables

The rule applications considered so far use rule conditions that are defined on some application data. That is, the concept of an event instance exists in the application and it may or may not be stored in the database. Often however, the data in the event instances correspond to some rows stored in relational tables. For such applications, the row identifiers (ROWIDs) of these rows can be used to pass the data to the Rules Manager procedures by reference, for example using the event_inst parameter to represent an event instance of the PROCESS_RULES call (event_inst => :FlightDataRowid). For this purpose, the corresponding event structure should be modeled using Expression Filter's table alias constructs. See the ADD_ELEMENTARY_ATTRIBUTE procedure for more information. See Chapter9 and Appendix A for more examples.

For the travel services application considered in Chapter2, if the AddFlight and AddRentalCar primitive events are stored in two relational tables FlightData and RentalCarData respectively, the corresponding composite event structure can be created to refer to rows in these tables as follows:

BEGIN  dbms_rlmgr.create_event_structure (event_structure => 'TSCompEvent');
  dbms_rlmgr.add_elementary_attribute (
                           event_structure => 'TSCompEvent',
                           attr_name => 'Flt', --- Prim event name
                           attr_type => exf$table_alias('FlightData'));
  dbms_rlmgr.add_elementary_attribute (
                           event_structure => 'TSCompEvent',
                           attr_name => 'Car', --- Prim event name
                           attr_type => exf$table_alias('RentalCarData'));
END;

Now the composite event structure TSCompEvent can be used to configure a rule class (Same as step 2 in Chapter2). The representation of the rules in the rule class does not vary with this event structure. However, within the action callback procedure, the primitive event instances that match a rule are each passed in as ROWIDs from the corresponding tables and these ROWIDs can be used to obtain the original event data. Also, with this new event structure, the primitive event instances, for which the rules are processed, are passed in by reference using the ROWIDs for the corresponding table rows.

BEGIN
  dbms_rlmgr.process_rules (
            rule_set_nm => 'TravelPromotion',
            event_type => 'FlightData',
            event_inst => :FlightDataRowid); -- rowid of a row ---
END;

Note that the conditions corresponding to a primitive event are evaluated when the dbms_rlmgr.process_rules procedure is invoked with the appropriate ROWID. However, Rules Manager does not keep track of any changes to the original row through an UPDATE operation.

Optionally, the PROCESS_RULES call can be eliminated by configuring the preceding rule class to consider all the INSERT operations into the corresponding tables as events. This is done by setting the DMLEVENTS property to "I" during rule class creation (see Chapter3). This specification automatically creates a few statement triggers that make the necessary PROCESS_RULES calls for the rule class.

When the duration and consumption policies are set for the primitive events derived from relational data, it is the references to the table rows that are consumed or deleted from the rule class. The original rows are not affected by these event management policies.A composite event structure can be formed using a combination of table alias constructs and embedded abstract data types (ADTs) (for various primitive events). The rule conditions defined for a composite event structure consisting of one or more table alias constructs may not use the (short form of) the SEQUENCE property to enforce sequencing among primitive events (see Chapter4). This is because the implicit attribute rlm$crttime may not exist for the rows stored in the relational tables. The user can enforce partial sequencing using the join property in the rule conditions.

Rules Conditions For XML Events

The XMLType data type supplied by Oracle can be used to create attributes in the event structures and rule classes that can process rules defined on XML documents. For this purpose, a primitive event structure can be created with one or more XMLType attributes (along with some non-XML attributes), such as the following:

CREATE or REPLACE TYPE AddFlight AS OBJECT (
                  CustId NUMBER,
                  Airline VARCHAR(20),
                  FromCity VARCHAR(30),
                  ToCity VARCHAR(30),
                  Depart DATE,
                  Return DATE,
                  Details sys.XMLType)

If a primitive event is just an XML document, then the preceding object type can be created with just one attribute, that is of XMLType. The predicates on the XMLType attributes are specified using the EXTRACT and EXISTSNODE operators supplied by Oracle, as shown in the following example.

<condition> <!-- optional for conditions on primitive events -->
   Airline='Abcair' and ToCity='Orlando' and
            EXTRACT(doc, '/preferences/seat[@class="economy"]') is not null
</condition>

A composite event structure for XML events can be formed by including two or more primitive event types that contain an XMLType attribute. So, the composite event structure is created as an object type with embedded primitive event types (as described in Chapter2). Once the event structures are created with XMLType attributes, all the other concepts described in Chapter2 apply to the XML data that is part of the events.

Rule Conditions with Spatial Predicates

The SDO_GEOMETRY data type supplied by Oracle can be used to create event structures and rule classes that can process rules defined on spatial geometries. For this purpose, a primitive event structure can be created with one or more attributes of the MDSYS.SDO_GEOMETRY type, as follows:

CREATE or REPLACE TYPE AddHotel AS OBJECT (
CustId    NUMBER,
Type      VARCHAR(20),
CheckIn   DATE,
CheckOut  DATE,
Location  MDSYS.SDO_GEOMETRY)

In order to specify predicates on the spatial attributes and index them for efficiency, the geometry metadata describing the dimension, lower and upper bounds, and tolerance in each dimension should be associated with each spatial geometry attribute. This metadata information can be inserted into the USER_SDO_GEOM_METADATA view using the event structure name in the place of the table name. For more information on the USER_SDO_GEOM_METADATA view and its semantics, see Oracle Spatial User's Guide and Reference.

INSERT INTO user_sdo_geom_metadata VALUES ('ADDHOTEL','LOCATION',
        mdsys.sdo_dim_array(
             mdsys.sdo_dim_element('X',  -180, 180, 0.5),
             mdsys.sdo_dim_element('Y',  -90, 90, 0.5)), 8307);

When the event structure with spatial attributes is used to create a rule class, the rule conditions stored in the rule class table can include predicates in these attributes using SDO_WITHIN_DISTANCE or SDO_RELATE operators, as shown in the following examples:

<condition>
  Type = 'Luxury' and CheckOut-CheckIn > 3 and  
    SDO_WITHIN_DISTANCE (Location,
      SDO_GEOMETRY(2001, 8307, 
        SDO_POINT_TYPE(-77.03644, 37.89868, NULL), NULL, NULL), 
      'distance=0.5 units=mile') = 'TRUE'
</condition>

<condition>
  Type = 'Luxury' and CheckOut-CheckIn > 3 and  
    SDO_RELATE (Location,
      SDO_GEOMETRY(2001, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), 
         SDO_ORDINATE_ARRAY(-77.03644, 37.89868, -75, 39), 
      'mask=anyinteract') = 'TRUE'
</condition>

A composite event structure involving spatial attributes can be formed by including two or more primitive event structures that contain SDO_GEOMETRY attributes. In the case of rules specified for composite events, the spatial predicates involving SDO_WITHIN_DISTANCE or SDO_RELATE operators are not allowed in the join clause of the rule condition. If needed, functions defined in the MDSYS.SDO_GEOM package may be used to achieve this functionality. See Oracle Spatial User's Guide and Reference for additional information.

Database State in Rule Conditions

The predicates in a rule condition may use user-defined functions, references to database table data, and database state information. In the case of a condition specified for a simple or a primitive event, the corresponding predicates are evaluated using the state information at the time the event is added to the rule class (using either the PROCESS_RULES or the ADD_EVENT call. This is the case even for conditions specified for individual primitive events within a composite event. So, when multiple primitive events are used to capture a composite event, the predicates associated with individual primitive events will be evaluated at different times, corresponding to the occurrences of their respective event. Only the predicates specified in the join attribute of the composite condition are evaluated at the time of composite event creation. So, this aspect should be considered when using database state or schema object references in the rule conditions.