T HE D EPARTMENT
OF I NFORMATION
S YSTEMS
PROF. DR. G E R T I K A P P E L J OHANNES K EPLER U NIVERSITY OF L INZ
A Tour on the TriGS Active Database System Architecture and Implementation
Gerti Kappel Stefan Rausch-Schott Werner Retschitzegger email: {gerti, stefan, werner}@ifs.uni-linz.ac.at
Altenbergerstraße 69, A-4040 Linz, Austria - Tel.: (+43) 732 / 2468-879 - Fax: (+43) 732 / 2468-9308 email:
[email protected] - http://www.ifs.uni-linz.ac.at
A Tour on the TriGS Active Database System Architecture and Implementation
Abstract. Research efforts in the area of active object-oriented database systems have been put mainly into the development of knowledge models and execution models without considering the consequences for their implementation. Thus, this paper is dedicated to implementation issues within the active object-oriented prototype system TriGS (Triggersystem for GemStone). One emphasis is put on the detection of composite events whose components should be allowed to span not only different transactions, but also different applications. Another emphasis is put on performance issues, in particular for rules which are defined to be executed in parallel. To realize these goals, first, composite event detection as well as rule scheduling is done in parallel to the event signaling application. Second, events which occur within an application transaction are immediately signaled, thus being visible across transaction boundaries. And third, rule processing is made efficient by means of several rule processors, whose number is dynamically controlled.
Keywords and Phrases. Active object-oriented database systems, ECA rules, composite events, parallel rule scheduling and processing, optimization
1 Introduction In the area of non-standard applications like computer integrated manufacturing and workflow management (re)active concepts have proven to be very useful. This became also apparent during the participation in an EC ESPRIT project (KBL, No. 5161) aiming at the development of next-generation production scheduling and control systems, which finally lead to the development of the prototype system TriGS [Kapp94a], [Kapp95]. TriGS builds upon the commercially available object-oriented database system GemStone1 [Gems95a] and is based upon a layered architecture [Rets96]. For its implementation, several design goals were followed: • Detection of Composite Events Spanning Several Applications. There are often situations where the different events which are part of a composite event do not occur within a single transaction but rather span several transactions and even several applications. This means, the active system should support composite event detection independent of the origin of the different components of the composite event. • Visibility of Events Across Transaction Boundaries. Some active systems do not allow to signal events for rules which should be executed in parallel to the event signaling transaction until the latter is finished. This, on the one hand increases reliability but on the other hand reduces efficiency. However, some application areas for rules require events to be signaled immediately independent of a proper termination of the event signaling transaction. Consequently, events occasionally have to be visible as soon as they occur, even across transaction boundaries. • Efficient Event Detection, Rule Scheduling and Processing. A critical factor of an active system is performance [Simo95]. This concerns event detection, rule scheduling and rule processing. To avoid that active capabilities decrease the performance of the event signaling application(s), the active components should work as far as possible in parallel to the event signaling application(s). In particular, this is possible in situations where the result of rule processing does not influence further processing of the application(s). 1 GemStone is a registered trademark of GemStone Systems Inc.
-2-
In this paper, we focus on implementational details of TriGS which were necessary to achieve these goals. For this, the remainder of this paper is organized as follows: Section 2 provides a concise overview of the knowledge model, the execution model, and the basic architecture of the system TriGS. Section 3 introduces the event detection component of TriGS, and Section 4 describes serial as well as parallel scheduling of rules. The rule processing component of TriGS is presented in Section 5. Finally, Section 6 provides a detailed discussion of related work and points to ongoing research.
2 Overview of TriGS In this section, we outline the concepts used in TriGS for specifying (re)active behavior, aspects concerning the execution of rules, and the basic architecture of TriGS. 2.1 Knowledge Model Like most active systems, TriGS is designed according to the ECA paradigm [Daya88]. Rules and their components are implemented as first-class objects allowing both the definition and modification of rules during run time. Figure 1 shows the basic structure for specifying rules in TriGS using the Backus-Naur Form (BNF). The symbols ::= [ ] are meta symbols belonging to the BNF formalism. Angle brackets denote non-terminal symbols. ::= DEFINE RULE AS ON
/* Condition event selector */
IF THEN
/* Condition part */
[[WAIT UNTIL] ON ]
/* Action event selector */
EXECUTE [INSTEAD]
/* Action part */
[WITH PRIORITY ] [TRANSACTION MODES(C:{serial|parallel},A:{serial|parallel})] END RULE .
Fig. 1. BNF of an ECA Rule in TriGS
The event part of a rule is represented by a condition event selector (EselC) and an optional action event selector (EselA) determining the events (e.g., a machine breakdown) which are able to trigger the rule’s condition and action, respectively. Triggering a rule’s condition (i.e., an event corresponding to the Esel C is signaled) implies that the condition has to be evaluated. If the condition evaluates to true, and an event corresponding to the EselA is also signaled, the rule’s action is executed. If the EselA is not specified, the action is executed immediately after the condition has been evaluated to true. By default, the thread of control signaling the condition triggering event is not blocked while the triggered rule is waiting for the action triggering event to occur. Blocking can be specified by the keyword WAIT UNTIL. In TriGS, any message sent to an object may signal a message event. Furthermore, TriGS supports time events, explicit events, and composite events similar to the approach described in SNOOP [Chak94]. Composite events consist of component events which may be primitive or composite and which are combined by different event operators such as conjunction, sequence and disjunction (for a more detailed description see [Rets96]). For each event, a guard similar to masks in ODE [Lieu96], i.e., a predicate over the event’s parameters, may be specified, which further restricts the events able to trigger condition or action, respectively. The condition part of a rule is specified by a boolean expression, possibly based on the result of a database query (e.g., are there some scheduled jobs on the damaged machine?). The action part is specified again in terms of messages (e.g., display all jobs scheduled on the damaged machine and reschedule them on another machine). Considering message-based rules, the keyword INSTEAD allows to specify that the action should be executed
-3-
instead of the method corresponding to the message triggering the condition evaluation. 2.2 Execution Model Concerning the execution of rules, most existing active systems use coupling modes in order to specify time semantics and transaction semantics for relating different rule components. TriGS, in contrast, makes a clear distinction between the specification of time semantics and the specification of transaction semantics allowing an orthogonal definition of these properties. Time semantics, on the one hand, is specified by means of an event-based approach [Kapp94b] which allows the specification of arbitrary points in time for condition evaluation and action execution. This is in contrast to coupling modes, which support only two points in time called immediate and deferred, i.e., at the end of the respective transaction. Transaction semantics, on the other hand, is defined by so called transaction modes, which can be separately specified for condition and action, respectively. The transaction mode specified for the condition called EC-Mode is relative to the condition triggering event whereas the transaction mode specified for the action called EA-Mode is relative to the action triggering event. TriGS supports two transaction modes, serial and parallel. A serial transaction mode (which is default) specifies that a condition/action is to be executed directly within the triggering transaction. Note, that some active systems [Gatz95] are using nested transactions [Agra96] instead. This has not been possible in TriGS due the lack of nested transactions in GemStone. A parallel transaction mode defines that a new independent top-level transaction in which the condition/action is executed is generated as soon as an appropriate event occurs. That is, both the triggering transaction and the rule transaction are allowed to proceed immediately after the event has been signaled. If both, condition and action, are triggered by the same event and for both a parallel transaction mode is specified, condition and action are processed within a single top level transaction. Multiple triggered rules, i.e., conditions and actions of different rules which are triggered at the same time, are scheduled according to priorities. Due to their parallel execution, however, it is not guaranteed that they are also finished in the scheduled order. For an in-depth discussion of the knowledge model and the execution model of TriGS we refer to [Kapp94a], [Kapp94b], [Kapp95], [Rets96]. 2.3 Basic Architecture The architecture of the TriGS prototype follows a layered approach. The object-oriented database system GemStone is responsible for providing traditional database functionality, as is required for an active system [Ditt95]. On top of GemStone, the following main components constituting the TriGS prototype are realized (cf. Figure 2): • Primitive event detectors (PEDs) for the detection of message events and explicit events within applications requiring active capabilities as well as within the rule processor in case of cascaded rule triggering. Note, that relative and periodic time events are detected by the Composite Event Detector. • Composite Event Detector (CED) for the detection of composite events in response to primitive events injected by Rule Schedulers. • Rule Schedulers (RSs) responsible for determining the rules which are triggered by the events signaled from the PEDs and the CED and for generating a schedule of triggered rules called ruleSchedule according to the rules’ priorities. • Rule Processors (RPs) for evaluating the conditions and executing the actions of the rules within the schedule generated by the RSs.
-4-
Figure 2 illustrates the interaction between a single RS, a certain CED, a certain RP, and two different PEDs. In the following sections, the tasks of each component are described in more detail.
signal ruleSchedule
signal composite events Composite Event Detector
Rule Processor
Rule Scheduler ExplEvent Detector
inject primitive events
Applications signal primitive events
MsgEvent Detector
Fig. 2. Components of TriGS
3 Event Detection 3.1 Primitive Event Detection In TriGS, the detection of primitive message events is realized by means of method wrappers similar to other active object-oriented database systems [Buch95], [Chak95], [Lieu96]. TriGS allows to wrap any user-defined method. Systemdefined methods can be wrapped within user-defined subclasses of those kernel classes wherein the system-defined methods are located. To avoid any unnecessary processing overhead, TriGS allows to unwrap methods if they are no longer needed as part of an event definition. Explicit events can be signaled simply by sending a specific message to the predefined class TriGSSystem together with desired parameter values. Similar to message events, an event object is generated, wherein the name of the signaled explicit event, its parameter values as well as a timestamp are stored. Time event detection is slightly different and will be described in more detail in Section 4. 3.2 Composite Event Detection For the representation and detection of a composite event, TriGS uses an extended syntax tree. In order to avoid redundant specification of subtrees representing composite events which themselves are part of other composite events, several syntax trees are combined to so called Extended Syntax Graphs (ESG). These ESGs are based on the work of SAMOS [Gatz95] and Sentinel [Chak95]. Each ESG consists of leaf nodes representing primitive event selectors, operator nodes corresponding to the event operators supported by TriGS, and arcs for establishing connections between them all. According to its intended semantics, an operator node contains a number of event buffers which are used to store component event objects that are waiting for other still missing component event objects. By means of three so called Event Injectors (EIs), one for each kind of primitive event, a signaled event is mapped to the respective leaf node of the ESG. The Active Rule Base (ARB) contains so called rule nodes which are connected with leaf nodes or those operator nodes "finalizing" event detection. They hold both the rule definition information and run-time information about event detection, rule scheduling, and rule processing. Two event buffers are used to store the event objects triggering condition evaluation and action execution respectively. Figure 3 illustrates the collaboration between event injection, composite event detection and rule triggering. It can be seen that E3 and E5 represent message event selectors, E4 an explicit event selector, and E1 and E2 time event selectors. The rule node R3 is referenced one time by the sequence operator node ";" depicting that it is able to inject the condition triggering event into R3 which corresponds to CE1 and another time by the leaf node E1, indicating that the action triggering event constitutes a primitive event. The condition triggering event and the action triggering event of R1 are iden-
-5-
tical, namely the composite event CE3. Thus, they are both injected by the COLL operator node, i.e., the action of R1 is immediately processed after the condition. Finally, condition and action of R2 are triggered by two composite events, corresponding to CE2 and CE3 in Figure 3. ARB RuleNode RuleDef
rule Schedule
R3 R2
CED
CE1
R1
CE2 CE3
;
COLL
not
RS
AND
OR
E3
E1
E2
E4
E5
Composite Event Definition: CE1:= E1 OR E3 ; NOT E4 ;CE2 CE2:= E1 AND E2 CE3:= COLL(CE2,E4,E5) Rule Definition: R1:= (CE3,Cond1,Act1) R2:= (CE2,Cond2,CE3,Act2) R3:= (CE1,Cond3,E1,Act3)
Legend:
EIs
ARB ... Active Rule Base RS ... Rule Scheduler CED ... Composite Event Detector EIs ... Event Injectors
MessageEI
ExplicitEI
signal primitive events
... rule node ... operator node ... leaf node
TimeEI
... event buffer ... event flow
Fig. 3. Collaboration between EIs, CED, and ARB
3.3 Origin and Visibility of Events In TriGS, message events as well as explicit events can occur within a GemStone transaction as well as outside, whereas time events occur outside of transactions only. Thus, if the triggering event of an event selector constitutes a time event, no triggering transaction exists wherein the rule could be processed. In this case the transaction mode for condition and/ or action is automatically set to parallel. ESigT
e1 e2
InitT e1
InitT
TrgT e2
...
TrgT RuleT
RuleT a) Single Transaction
Legend:
e1 e2
RuleT c) Multiple Ts within several threads
b) Multiple Ts within single thread
TrgT
... triggering transaction
RuleT
... rule transaction
InitT
... initializing transaction
ei
... signaled event
ESigT
... event signaling transaction
... relationship
Fig. 4. Composite Events and Transactions
Origin of Events. Concerning the origin of component events occurring within transactions, three different cases can be distinguished. All component events occur in a single transaction (Figure 4a), or some of them occur in different transactions. Concerning the latter case, there are again two possibilities: Either the event signaling transactions are sequentially processed within a single thread of control (Figure 4b), or they are executed within different threads of control (Figure 4c). Any of these cases results in a many-to-one relationship between event signaling transactions and a rule transaction. Note, that these different origins are also valid for primitive condition triggering events and action triggering events, respectively. For example, the action triggering event may occur in another thread than the condition triggering event.
-6-
Figure 5 shows the transaction modes which are allowed in TriGS depending on the origins of the events constituting a composite event of a certain rule. It can be seen that the parallel transaction mode covers all scenarios of event origins illustrated in Figure 4. Unlike the serial transaction mode, the parallel transaction mode even allows that component events occur across different applications, i.e., different threads of control.
T-Mode
Origin of Component Events Outside of a T
Single T
Multiple Ts/ Single Thread
Multiple Ts/ Multiple Thread
serial
✓
✓
✓
✘
parallel
✓
✓
✓
✓
Fig. 5. Origins of Component Events in TriGS
Visibility of Events. In case that an event occurs within a transaction, the event detector immediately signals the event to the responsible RS in order to increase efficiency instead of waiting for the successful termination of the triggering transaction. One has to be aware, however, that if such an event participates in triggering a rule which is specified to be parallel, the increased efficiency is at the cost of reduced reliability because of the relaxed isolation property of the event signaling transactions.
4 Rule Scheduling In TriGS, several rule schedulers are responsible for scheduling triggered rules, namely one attached rule scheduler (ARS) per thread and a single detached rule scheduler (DRS) responsible for all threads. 4.1 Serial Rule Scheduling An ARS manages rules which according to their transaction modes have to be processed serial to the triggering transaction. Thus, an ARS is able to process only those composite events spanning just one application. Thus, an ARS is able to process only those composite events spanning just one application. Since each application process requiring active capabilities has its own copy of an ARS, access conflicts between different application processes are avoided. Furthermore, each ARS runs within the process of that application it is attached to. Figure 6 illustrates the process architecture of the ARS. It can be seen that not only rule scheduling is done within the application process but also primitive and composite event detection and rule processing.
Rule Processor Composite Event Detector
Application 1 Application 2 ..... Application n
Attached Rule Scheduler Legend:
PEDs
PEDs ... Primitive Event Detectors ... processes
Fig. 6. Process Architecture of the Attached Rule Scheduler
If a primitive event is signaled to the ARS of the application then the event signaling transaction is interrupted until the event is fully processed. Different cases can be distinguished: • If the event which has been signaled is only a component event but not a triggering event, the event signaling transaction only has to wait until the event has been injected and processed by the CED.
-7-
• If the event which has been signaled is the triggering event for some conditions or actions then the triggering transaction has to wait until the triggered conditions and/or actions have been identified, scheduled and processed. • If due to processing of conditions and/or actions new conditions and/or actions are cascadedly triggered then the triggering transaction has to wait further on. In the case of a serial transaction mode for the newly triggered rules it has to wait until the rules are processed. In the case of a parallel transaction mode the triggering transaction has to wait only until the event is signaled to the DRS. Serial rule processing is done for all those rules scheduled by the ARS. Since it takes place within the triggering transaction immediately after signaling the terminating event and scheduling all appropriate rules, rule processing requires a simple method call only. 4.2 Parallel Rule Scheduling Unlike the ARS, the Detached Rule Scheduler (DRS) is responsible for scheduling the triggered conditions and actions which according to their transaction modes have to be processed parallel to the triggering transaction. Figure 7 illustrates the process architecture of the DRS.
TriGS Controller Legend:
Rule Processor
PEDs ... Primitive Event Detectors ... processes
Composite Event Detector
Detached Rule Scheduler
PEDs
Application 1 Application 2 ...... Application n
Fig. 7. Process Architecture of the Detached Rule Scheduler
In contrast to the ARS, there exists a single DRS only, which runs in a separate process together with the CED. The DRS is able to process composite events spanning different applications. For this, the PEDs signaling these events are executed within each application process and communicate with the DRS by means of interprocess communication. Note that these PEDs may be shared with the ARSs responsible for scheduling and processing serial rules triggered by the respective applications. To realize the semantics of processing rules in parallel to the triggering transaction, the application signaling the event is suspended only until the event has been passed from the PEDs to the DRS. The DRS performs a scheduling cycle, where each cycle processes a received event. This event is used both, to trigger rules from the ARB and to proceed the detection of composite events by injecting it into the CED. In order to realize processing of these rules in parallel to each other, a number of rule processors (RPs) running in different processes is used. The RPs are notified by the DRS about a complete schedule which initiates rule processing (cf. Section 5.1). The result of condition evaluation as well as new events which occur during rule processing have to be transferred back to the DRS (cf. Section 5.2). The number of RPs is dynamically adapted according to their utilization by the TriGS Controller (cf. Section 5.3). Figure 8 presents the functional architecture of the DRS. Its concepts and elements are described in more detail in the following.
-8-
Detached Rule Scheduler signal composite events inject primitive events
Active Rule Base
signal ruleSchedule
trigger rules Event Injectors
signal absolute/ relative time events
scheduling cycle event Schedule
timeEvent Schedule
Operating System
Exception Handler for G2G Signals
signal primitive events
signal primitve events
Fig. 8. Functional Architecture of the Detached Rule Scheduler
Signaling and Receiving Message Events and Explicit Events. The DRS is notified about message events and explicit events on the basis of interprocess communication. This communication is realized by means of GemStone’s GemTo-Gem (G2G) signals. A G2G signal is a signal which can be sent between two GemStone sessions. A Gemstone session is established each time an application logs into GemStone and corresponds to an operating system process. In order to react to a G2G signal, an appropriate exception handler method has to be installed for a session. Upon signaling, the currently executed method is automatically suspended for the duration of the exception handler method. Afterwards the current process is resumed. The advantage of this mechanism compared to alternative solutions like UNIX sockets or named pipes [Good94] is that communication is not done indirectly via the operating system but rather straightforward via GemStone. Since the amount of data which is communicated is very small, G2G signals are an appropriate solution. Time events are inserted in form of time event objects into a timeEventSchedule as soon as the occurrence time is known. This timeEventSchedule is processed as part of the so called scheduling cycle which is described next. The Scheduling Cycle. The scheduling cycle of the DRS starts as soon as either the exception handler has inserted an event object into the queue named eventSchedule, or an absolute time event is signaled by the operating system. During this cycle, the following steps are undertaken by the DRS based on timestamps of the event objects. Note, that timestamps of events across applications are comparable, since they are all generated by the database system which is shared by all applications. (1) The DRS first checks if there are events waiting within eventSchedule and/or within timeEventSchedule (2) Scenario 1: If there are events within eventSchedule and within timeEventSchedule, then the DRS determines if the timestamp of the first element within timeEventSchedule is less or equal the system time and the timestamp of the first element within eventSchedule. If there is one, it is further processed by the DRS. Note, that in the current implementation the granularity of a timestamp is one second. If there are further time events having the same timestamp, all these events are processed by the DRS one by one, and all rules triggered by these events are part of the same schedule. Note, the processing of events found in one of these scenarios includes their injection into the CED and the scheduling of thereby triggered rules. Also, further relative or periodic time events which are detected by the CED may be inserted into timeEventSchedule.
-9-
(3) Scenario 2: If there are no pending time events but there exist events within eventSchedule the DRS proceeds with these events. Analogously to time events, if several events within eventSchedule have the same timestamp they are part of the same schedule. (4) Scenario 3: If there is no pending time event and the eventSchedule is empty, the DRS does not have any work to do and therefore sets itself inactive. In case that timeEventSchedule is not empty, but the timestamp of the next event is higher than system time, the operating system is notified about the next absolute time event. With this information, the operating system is able to activate the inactive DRS in time by using the UNIX command SIGALRM [Good94]. At any time during a scheduling cycle, a new message event or an explicit event can be signaled to the DRS. In this case, the scheduling cycle is interrupted only until the event is received by a GemStone exception handler. If during the scheduling cycle an absolute time event is signaled by a SIGALRM it has no effect. The pending absolute time event already exists within the timeEventSchedule and will be processed as soon as all events having a lower timestamp have been dealt with.
5 Parallel Rule Processing Once all rules triggered at a certain point in time have been scheduled by the DRS within the queue ruleSchedule, i.e., a certain scheduling cycle is completed, these scheduled objects (conditions and actions) are further processed by Rule Processors. 5.1 Notification and Synchronization of Rule Processors As soon as a schedule is complete, i.e., all rules triggered by events having the same timestamp are within ruleSchedule, the RPs have to be informed. This is necessary, since the RPs are inactive if they have already finished processing all former schedules and the new schedule is not yet complete. Instead of periodically polling ruleSchedule, the information about a new complete schedule is gathered by means of a semaphore called counter semaphore (#0). This semaphore represents the actual number of elements within ruleSchedule. The synchronization between RPs which concurrently access ruleSchedule is done via an additional semaphore, called synchronization semaphore (#1). This semaphore denotes the actual status of ruleSchedule: a value of 0 depicts that another Rule Processor is just dequeuing a schedule object, whereas a value of 1 denotes that ruleSchedule is currently not accessed. The main reason for using a semaphore for this synchronization rather than using GemStone locks is that, by means of the so called "P-operation", it can be waited for the occurrence of two or more semaphores without producing a deadlock [Good94]. A third semaphore (#2) called utilization semaphore is used to compute the utilization of the Rule Processors (cf. Section 5.3). Two operations on these semaphores are used in order to synchronize the processes (cf. Figure 9). The operation Pi,j(n,m) forces the process to wait until the values of the semaphores i and j are equal or higher than the values of n and m. If true, the values of the semaphores are reduced by n and m [Good94]. The operation Vi(j) increases the value of the semaphore i by j. At runtime, the DRS increases the counter semaphore to the number n of schedule objects which were enqueued into ruleSchedule by means of the operation V0(n). Each Rule Processor waits by means of the operation P0,1(1,1) as long as at least one element has been inserted into ruleSchedule and no other Rule Processor is accessing ruleSchedule. Then, it dequeues a schedule object from ruleSchedule, commits the transaction and increases the value of the synchronization semaphore by means of V1(1). The dequeued schedule object is provided as a parameter for the - 10 -
messages detachedEval:cond or detachedExec:act, which are sent to the class TriGSSystem. Condition evaluation and action execution are both finished by a commit operation. In addition, this operation is signaled to the rule scheduling process by a message event occurring due to the condition and action processing methods. At begin and end of each condition and action processing step, the operations V2(1) and P2(1) are executed, respectively. In this way, the third semaphore always represents the actual number of active Rule Processors. The utilization, thus, can be computed by dividing this value by the number of started Rule Processors (cf. Section 5.3).
begin
e1
e2
e3
V0(2)
V0(3)
V0(1)
DRS
RP1:
begin
rm
V1(1)
process
P0,1(1,1)
RP3:
V1(1)
process
P0,1(1,1)
begin
RP2:
rm
rm
V1(1)
process
P0,1(1,1)
rm
P0,1(1,1)
V1(1)
process P0,1(1,1)
P0,1(1,1) V1(1) rm
begin
process
P0,1(1,1)
V1(1) process rm
P0,1(1,1)
P0,1(1,1)
Legend: DRS
... Detached Rule Scheduler
... synchronization
RPi
... Rule Processor
... commit ... abort
Pi,j(n,m) ... wait for semaphores i and j and decrease them Vi(j)
... increase semaphore i with value j
ei
... primitive event
rm
... dequeued a schedule object
... active process process ... process rule
... waiting process
Fig. 9. Synchronization of Rule Processors and Communication with the DRS
In order to achieve concurrency between the DRS, which is generating a new schedule, and the different RPs, processing conditions and actions of an older schedule, GemStone’s semantic concurrency control mechanisms are used for the queue ruleSchedule. By realizing ruleSchedule as a so called reduced conflict queue, it is ensured that even if the DRS enqueues a new scheduling object, one of the Rule Processors can dequeue an already stored scheduling object at the same time. Figure 9 illustrates the communication between the DRS and three different Rule Processors as well as their synchronization on the basis of semaphores. It is assumed that three different primitive events e1, e2, and e3 were signaled to the DRS. The event e1 triggers two rules, i.e., ruleSchedule contains two schedule objects. It can be seen that both rules are processed in parallel by RP1 and RP2. Further on, e2 triggers three rules and e3 triggers a single rule, only. At that point in time, all RPs are still engaged in processing the rules triggered by e2. Therefore, the last schedule containing the rules which were triggered by e3 has to wait until one of the RPs has finished processing. Note, that it would be possible to dynamically increase the number of RPs in order to prevent from such delays (see Section 5.3). 5.2 Communication between RP and DRS There are two situations where a RP has to communicate with the DRS. First, as soon as the RP has finished evaluating a condition, the DRS has to be informed about the result. Second, in case that a rule processed by the RP signals further events, the DRS has to schedule cascadedly triggered rules.
- 11 -
End of Condition Evaluation. As soon as a rule processor has evaluated a certain condition, the DRS has to be informed that condition evaluation has finished independent of the result of the evaluation, in order to take all steps necessary for scheduling the action of the rule. This notification is done by reusing the functionality of TriGS itself. The class method responsible for parallel condition evaluation, detachedEval:for:, and the class this message is sent to, TriGSSystem, are simply made part of an event selector. With this, after every parallel condition evaluation, a message event is signaled to the DRS. The parameters of this message event include the name of the rule, the triggering event and the result of condition evaluation. If the condition evaluation transaction is aborted, the evaluation result is NIL. Cascaded Rule Processing. It is possible that during parallel condition evaluation or action execution new message events occur. These events are allowed to trigger rules that have either again specified a parallel transaction mode, or that have a serial transaction mode. This is possible since every time a new RP is started, an ARS is automatically assigned to this RP. Concerning the processing strategy for cascadedly triggered rules, unlike serial rule processing, no generally valid statement about whether to process cascaded rules in a depth-first or breadth-first order can be given. Thus, even in case that a rule R1 which triggers another rule R2 involves a time consuming condition or action, a depth-first processing strategy might be used. Consequently, R2 can "overtake" R1 if both, scheduling and processing of the triggered rule R2 takes less time then processing of the triggering rule R1 itself. 5.3 Managing the Components of TriGS - TriGS Controller The TriGS Controller manages all processes responsible for realizing parallel composite event detection, parallel rule scheduling and parallel rule processing. For this, it starts a dedicated child process for detached rule scheduling as well as a number of predefined child processes realizing parallel condition and action processing. Unfortunately, parallel rule processing cannot be realized straightforwardly in GemStone for two reasons. First, although a GemStone application may establish more than one GemStone session, only one session can be active at a time. And second, within a single GemStone session, transactions can only be executed serially. In order to realize parallel rule processing, either a new GemStone session has to be started every time it is needed thus constituting a new UNIX process, or an already started and currently inactive GemStone session has to be used. The implementation combines both alternatives. At TriGS start-up time, a predefined number of GemStone sessions for rule processing is started. These sessions concurrently retrieve conditions and actions out of ruleSchedule and process them. The number of these parallel Rule Processors is dynamically adapted by the TriGS Controller according to their utilization. The desired utilization can be configured by the user. Note, that child processes are realized by lightweight processes which share the same code section, the same data section and other operating resources [Good94]. The TriGS Controller is implemented in C, the connection to GemStone is realized by means of the GemStone C Interface (GCI) [Gems95b]. TriGS Controller
Parent Process:
Legend:
Child Processes:
DRS
RP1
RP2 ... RPn
DRS ... Detached Rule Scheduler RPi ... Rule Processor
Fig. 10. Process Structure for Parallel Rule Processing
Configuration Options for TriGS Controller. Several configuration options are used on the one hand for correctly logging into GemStone and on the other hand for controlling the child processes. For example, the option -noRS obviates the activation of detached rule scheduling. This is especially useful if there still exist triggered rules which have to be executed whereas at the same time triggering of new parallel rules should be prevented. This scenario of unprocessed but - 12 -
already scheduled conditions and actions can happen if TriGS is stopped before all conditions and actions have been processed. Dynamic Adaptation of the Number of Rule Processors. At start-up, Rule Processors are started. After every seconds, the relative utilization of the existing Rule Processors is computed. The default value for sample rate is three. For example, in the presence of five Rule Processors an utilization of 60 percent means, that three of these processes are currently processing conditions and actions, whereas the others are waiting or at this point in time are accessing the queue ruleSchedule. After every number of sample rates, the average over all former sample rates is computed. If this value falls below percent, and the actual number of Rule Processors still exceeds , one inactive Rule Processor is selected arbitrarily for termination. In case that the average utilization is higher than percent, and the actual number of Rule Processors is still lower than , a new Rule Processor is started.
6 Related Work and Outlook There are only few architectural and implementational details available about existing active object-oriented database systems. For this reason, we restrict our comparison, which is illustrated in Figure 11, to the active systems REACH [Buch95], SAMOS [Gatz95], Sentinel [Chak95], and Ode [Lieu96]. Origin of Component Events. Considering the origin of events constituting a composite event, all systems except Sentinel allow that component events can be signaled from multiple transactions within different threads. Immediate Visibility of Events. Concerning the visibility of events, we have to consider how composite events are internally represented by the different systems. In SAMOS and Ode, composite events internally are represented within a complex database object structure. In Sentinel, component events are represented in main memory and flushed at commit of the corresponding event signaling transactions. Consequently, composite events in all three systems are detected not before commit of all but the last one participating event signaling transactions. This further means, that transactionspanning composite events imply a deferred coupling mode. Only the final transaction need not have committed and may execute the trigger in immediate coupling mode as well. In SAMOS, composite events might even produce deadlocks between the event signaling transactions and, thus, prohibit their detection. In contrast, REACH seems to allow to signal composite events before commit of the participating event signaling transactions, but it is not clear from literature. Parallel Composite Event Detection and Rule Scheduling. The detection of composite events and the scheduling of rules that are triggered by primitive or composite events might be performed as part of the event signaling transaction or within a separate thread of control running parallel to the event signaling transaction. In the first case, thus, event detection and/or rule scheduling occasionally suspends the execution of the event signaling transaction for a considerably long amount of time. Ode and SAMOS do not allow for parallel detection of composite events due to restrictions of the underlying architecture. In case that multiple rules are triggered simultaneously, these rules may in addition be scheduled in parallel to each other. This is supported only in REACH by means of several concurrently running ECA managers, each responsible for detecting a certain kind of event and scheduling rules triggered by that event. Parallel Rule Processing. Similar to the former criterion, rules with decoupled semantics may be processed either as part of the event signaling transaction or within a separate thread of control in parallel. As the only system, Ode adheres to the first case. A separate (dependent or independent) coupling mode in Ode implies that the rule is processed within a separate top-level transaction that is serialized behind the triggering transaction. In case of multiple rules triggered simul-
- 13 -
taneously, it has to be decided whether these rules are processed in parallel to each other or not. This is supported or at least planned to be integrated into future versions by all of the compared systems. Figure 11 summarizes the differences between TriGS and other active systems with respect to the above mentioned
SAMOS
TriGS
✓ ✓ ✓
✓ ✓ ✓
✓ ? ✓*
✓ ✓ ✓
✓ ✓ ✓
Immediate Visibility of Events
✘
✘
✓*
✘
✓
Parallel Composite Event Detection and Rule Scheduling - to event signaling transaction - to other rules to be scheduled
✘ ✘
✓ ✓
✓ ✘
✘ ✘
✓ ✘
Parallel Rule Processing - to event signaling transaction - to other rules to be processed
✘ ✓*
✓ ✓*
✓* ✓
✓ ✓
✓ ✓
Legend: ✓ ... supported
REACH
Origin of Component Events - single transaction - multiple transactions within a single thread - multiple transactions within different threads
Ode
Sentinel
criteria.
✘ ... not supported
✓* ... not yet implemented
- ... not applicable
? ... not clear from literature
Fig. 11. Comparison to Related Approaches
Despite the fact that the TriGS prototype has implemented some useful features concerning origin and visibility of events as well as parallelism of rule scheduling and processing, there are still a lot of open issues. One major aspect we want to consider in the near future is the integration of additional transaction semantics into the TriGS prototype based on an extension of the nested transaction model [Kapp96].
References [Adel91]
H. Adelsberger, J. Kanet, The Leitstand - A New Tool for Computer Integrated Manufacturing, Production and Inventory Management Journal, First Quarter, 1991
[Agra96]
D. Agrawal, A.El Abbadi, Transaction Management in OOMDBS, Object-Oriented Multidatabase Systems, A. Elmagarmid, O. Bukresh (eds.), Prentice Hall, 1996
[Buch95]
A.P. Buchmann, J. Zimmermann, J.A. Blakeley, D.L. Wells, Building an Integrated Active OODBMS: Requirements, Architecture, and Design Decisions, in P. S. Yu, A. L. P. Chen (eds.), Proceedings of the 11th International Conference on Data Engineering (ICDE ’95), IEEE Computer Society Press, Taipeh, Taiwan, March 1995
[Chak94]
S. Chakravarthy, V. Krishnaprasad, E. Anwar, S.-K. Kim, Composite Events for Active Databases: Semantics, Contexts, and Detection, in Proceedings of the 20th International Conference on Very Large Data Bases (VLDB ’94), J.B. Bocca, M. Jarke, C. Zaniolo (eds.), Morgan Kaufmann, Santiago, Chile, Sept. 1994
[Chak95]
S. Chakravarthy, V. Krishnaprasad, Z. Tamizuddin, R.H. Badani, ECA Rule Integration into an OODBMS: Architecture and Implementation, in P. S. Yu, A. L. P. Chen (eds.), Proceedings of the 11th International Conference on Data Engineering (ICDE ’95), IEEE Computer Society Press, Taipei, Taiwan, March 1995
[Daya88]
U. Dayal et al., The HiPAC Project: Combining Active Databases and Timing Constraints, in Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, H. Boral, Per-Åke Larson (eds.), SIGMOD Record, 17(3), Chicago, Illinois, Sept. 1988
[Ditt95]
K.R. Dittrich, S. Gatziu, A. Geppert, The Active Database Management System Manifesto: A Rulebase of ADBMS Features, in Proceedings of the 2nd Workshop on Rules in Databases (RIDS ’95), T. Sellis (ed.), Springer LNCS 985, Athens, Greece, Sept. 1995
[Gatz95]
S. Gatziu, Events in an Active Object-Oriented Database System, PhD, Kovac, 1995
[Gems95a] GemStone Programming Guide, Version 4.1, July 1995 [Gems95b] GemStone C Interface, July 1995 - 14 -
[Good94]
B. Goodheart, J. Cox, Unix System V Release 4, Prentice Hall, Munich, 1994
[Härd93]
T. Härder, K. Rothermel, Concurrency Control Issues in Nested Transactions, VLDB Journal, 2(1), G. Schlageter (ed.), 1993
[Kapp94a] G. Kappel, S. Rausch-Schott, W. Retschitzegger, S. Vieweg, TriGS - Making a Passive Object-Oriented Database System Active, Journal of Object-Oriented Programming (JOOP), July/Aug. 1994 [Kapp94b] G. Kappel, S. Rausch-Schott, W. Retschitzegger, Beyond Coupling Modes - Implementing Active Concepts on Top of a Commercial ooDBMS, in Proceedings of the International Symposium on Object-Oriented Methodologies and Systems (ISOOMS), Springer LNCS 858, Palermo, Italy, Sept. 1994 [Kapp95]
G. Kappel, S. Rausch-Schott, W. Retschitzegger, A M. Tjoa, S. Vieweg, R. Wagner, Active Object-Oriented Database Systems For CIM Applications, Information Management in Computer Integrated Manufacturing, A Comprehensive Guide to State-of-the-Art CIM Solutions, H. Adelsberger, J. Lazansky, V. Marik (eds.), Springer LNCS Tutorial, 1995
[Kapp96]
G. Kappel, S. Rausch-Schott, W. Retschitzegger, M. Sakkinen, Multi-Parent Subtransactions - Covering the Transactional Needs of Composite Events, International Workshop on Advanced Transaction Models and Architectures (ATMA), Goa (India), Sept. 1996
[Lieu96]
D.F. Lieuwen, N. Gehani, R. Arlein, The Ode Active Database: Trigger Semantics and Implementation, in Proceedings of the 12th International Conference on Data Engineering (ICDE ’96), IEEE Computer Society Press, New Orleans, Louisiana, March 1996
[Rets96]
W. Retschitzegger, A Tour on TriGS - Development of an Active System and Application of Rule Patterns for Active Database Design, PhD, Department of Information Systems, Johannes Kepler University of Linz, Sept. 1996
[Simo95]
E. Simon, A. Kotz-Dittrich, Promises and Realities of Active Database Systems, in Proc. of 21th Int. Conference on Very Large Data Bases (VLDB ’95), U. Dayal, P.M.D. Gray, S. Nishio (eds.), Morgan Kaufmann, Zurich, Switzerland, Sept. 1995
- 15 -
