CAPÍTULO III .EL BIEN JURÍDICO Y SU ANÁLISIS CON RESPECTO AL BIEN
2. BIEN JURÍDICO
4.4.1 Implicit Inter-Transaction Concurrency
Markus Kirchberg
As typical for DBSs, independent transactions are executed simultaneously whenever possible. The two most commonly considered properties, affecting the degree of in terleaving, are serialisability (that is conflict-serialisability) and recoverability. This, of course, is also the case for transactions in iDBPQL that stem from different user programs, i.e. originate from different main evaluation plans. The TMS scheduler de termines the degree of interleaving of operations of such transactions. Section 5.2.2 will later introduce a corresponding prototype. Transactions that belong to the same main evaluation plan may be executed serially or interleaved. The programmer has a greater influence over the mode of execution. Corresponding details are outlined next.
4.4.2 S upport for Explicit Concurrency
Inter- and intra-transaction concurrency may be specified explicitly. iDBPQL provides two different control flow expressions that imply concurrency.
On one hand, it can be specified that a block of statements may be executed inde pendently from its surrounding statements (i.e. time sharing or MIMD) . Thus, different, independent statements are processed at the same time. When specified within a loop statement, this time sharing or MIMD approach is mixed with SIMD. The general syntax for such a specification is as follows:
Syntax Snapshot 4 . 2 1 {Independent iDBPQL Blocks}
IndependentDoBlock = " INDEPENDENT" , " DO " , Statement s , "ENDD O " ;
D
Whether or not independent execution results in multi-tasking, single-threaded or multi-threaded execution is indicated by the compiler and / or decided at execution time.
EXAMPLE 4 . 22 . Let us consider some examples. First, we consider the simultaneous
execution of two independent statements, which belong to the same transaction (i.e. utilising intra-transaction con currency) .
0 1 PUBLIC EVALPLAN ViewProf ile ( ) { 02 doSomething ; 03 04 LABEL i 1 : INDEPENDENT DO 05 doSomethingindependently ; 06 ENDDD ; 07 08 doSomethingElse ; 09
// imp l ementat ion of a p ers i s t ent me thod of /1 c l ass Univers itycc . StudentC
1 0 WAIT i 1 ; // synchronis a t ion o f main execut ion stre am w i t h independent s tream
1 1
1 2 doMore ; 1 3 }
From line 0 1 to line 04 execution has been serial. In line 04, an independent execution block is declared. Together with t his execution block declaration (i.e. INDEPENDENT
4.4. SIMULTANEOUS PROCESSING Markus Kirchberg DO) a label is specified. This label is used later to synchronise the independent execution stream (i.e. the doSomethingindependently block) with the main exe cution stream (i.e. doSomethingElse) . Serial execution continues from line 12 onwards. Secondly, we consider this type of processing when executing two transactions that be long to the same request / evaluation plan (i.e. explicit inter-transaction concurrency) . 20 {
2 1 / / cons i der a n eva Lua t i on p L an us ing the University schema
22 I NDEPENDENT DO TRANSACTI ON tr1
23 stNumb = LectureC . countStudents ( ) WHERE ( course . cNumb == " 157 . * " ) ; 24 tr l . commit ( ) ;
25 ENDDO ;
26
27 DO TRANSACTION tr2
28 FOR EACH CourseC AS x {
29 selectedPapers . add ( x WHERE x . cNumb == " 157 . * " ) ;
30 }
3 1 tr2 . commit ( ) ; 32 ENDDO ;
33
34 }
Transactions tr1 and tr2 are executed concurrently. No synchronisation command has been specified. Thus, both execution streams are only synchronised at the end of the corresponding block, i.e. line 34.
Finally, we will utilise the repetitive simultaneous execution of a block of independent statements on a common data set. In this example, we intend to process all statements of one iteration in a for each loop simultaneously with all statements of the next iteration etc.
40
4 1 F O R EACH StudentC A S x INDEPENDENT DD 42 doSomething ;
43 ENDDO ;
44
The doSomething-block is invoked independently for each object in class StudentC. Thus, we could also write:
50 5 1 LABEL i l : INDEPENDENT DO 52 x = StudentC . f irst ( ) ; 53 doSomething ; 54 ENDDO ; 55 56 LABEL i2 : I NDEPENDENT DO 57 x = StudentC . next ( ) ; 58 doSomething ; 59 ENDDO ; 60
4.4. SIMULTANEOUS PROCESSING Markus K irchberg 6 1 LABEL i3 : INDEPENDENT DO 62 x = StudentC . next ( ) ; 63 doSomething ; 64 ENDDO ; 65 66 67 LABEL in : INDEPENDENT DO 68 x = StudentC . last ( ) ; 69 doSomething ; 70 ENDDO ; 7 1 7 2 WAIT i 1 , i2 , i 3 , . . . , in ; 73 D
On the other hand, it can be specified that a block of statements is executed concur rently while preserving the indicated ordering. This type of processing is particularly useful when processing collections. Let us consider an example:
EXAMPLE 4 . 2 3 . Assume, we have a database that keeps track of student enrolments. Students have to apply for course enrolments. They will be approved into a particular course only if they meet all course pre-requisites. Before the beginning of a new semester we like to execute a routine that automatically approves applications which meet all respective course pre-requisites. Subsequently, we have to contact all students whose applications could not be approved automatically.
This procedure can be done in two subsequent steps. Alternatively, we could utilise concurrency (to be more precise, pipelining) . This may be achieved as follows:
ForEach s tudent Do in para l l e l
Aut omat i c a l ly approve a l l cours e app l i cat i ons . Then
Comp i l e a l i s t of s tudents which have at l eas t one unapproved app l i ca t i on .
EndDo
Obviously, it is vital that the execution ordering is preserved. D
In iDBPQL, we support this type of execution. The general syntax for such a spec ification is based on the FOR EACH loop statement:
S yntax S napshot 4 . 22 {Concurrent iDBPQL Blocks}
ConcurrentForEachBlock = "FOR EACH" , Express ion , "CONCURRENT" , "DO " , Statements , { "THEN" , "DO " , Stat ements , "ENDD O " , '; ' } ,
" ENDDO" , ' ; '
D The evaluation of the expression results in a collection value. Members of this collec tion are made available to the DO-statement first. Once those values have been processed they are pipelined to the THEN DO-statement. Thus, both statements may execute si multaneous while preserving execution ordering.
4.4. SIMULTANEOUS P ROCESSING Markus Kirchberg
EXAMPLE 4 . 2 4 . Let us consider some examples. First, we will call two methods on a collection of objects. The second method may be invoked on each object on which the first method has been executed successfully, i.e. objects are pipelined from the first invocation statement to the second invocation statement.
0 1
02 FOR EACH myCollect ion CONCURRENT DO
03 myCollection . sort ( ) ; // sorts a � � members in the co � � e c t ion, e . g . a � i s t
04 THEN DO
05 myCollect ion . el iminateDuplicatesSorted ( ) ; /1 b ased on a sort ed
06 / 1 co � � e c t ion, dup � i ca t es are e � imina t ed by cons i dering 'neighb ouring '
07 ENDDO ; // c o � � e c t i on memb e rs
08 ENDDO ;
09
Line 02 indicates the start of a block of statements that is to be executed con currently. The two statements in lines 03 and 05 operate on the same collections and, thus, may execute concurrently as long as the execution order is preserved per collection object. So, every object that the myC o l lection . s ort ( ) ; statement releases (i.e. adds to its associated result queue) is passed on (i.e. pipelined) to the
myCollec t i on . eliminateDuplicates ( ) ; statement. As a result, the execution of both statements may overlap (in a controlled manner) .
Another means of specifying order-preserving, concurrent execution is within a for
loop. Within a for each-loop the pipelined object is selected explicitly. In addition to the CONCURRENT DO, we also have an INDEPENDENT DO in this loop.
1 0
1 1 FOR EACH mydb . SalaryC AS x CONCURRENT DO 1 2 x . addBonus ( 2 , 000 ); 1 3 THEN DO 14 1 5 Label i 1 : INDEPENDENT DO 1 6 x . printPaymentSlip ( ) ; 1 7 ENDDO ; 1 8
1 9 extMail . add ( x ) WHERE x . has inHouseMailAddress ( ) = = FALSE ; 20
2 1 WAIT i 1 ; 22
23 ENDDO ;
24 THEN DO
25 x . salaryProcessed ( date . today ( ) , t ime . now ( ) ) ; 26 ENDDO ;
27 ENDDO ; 28
For each object x in the collection-class mydb . SalaryC, the addBonus method is in voked. Subsequently, this object is pipelined to both the execution unit invoking the
printPaymentSlip method as well as to the execution unit that maintains a set of salary objects that do not satisfy the boolean has inHous eMailAddress method. Once,
4.4. SIMULTANEOUS PROCESSING Markus Kirchberg
both invocations have been completed (refer to the WAIT in line 2 1), we can pipeline the object x to the fourth execution unit invoking the salaryProcessed method. While both order-preserving examples outlined above only refer to operations within a single transaction, the same concept can be applied across transactions. Let us demon strate this next:
30
3 1 DO TRANSACTION tr1
32 salCol = mydb . SalaryC ;
33
34 DO TRANSACTION tr2
35 FOR EACH salCol AS salObj CONCURRENT DD TRANSACTION tr1
36 salObj . addBonus ( 2 , 000 ); 37
38 THEN DD TRANSACTION tr2 // imp L i es ordering : tr1 THEN tr2
39 salObj . printPaymentSlip ( ) ; 40 ENDDO ; 41 ENDDO ; 42 ENDDO ; 43 ENDDO ; 44
Here, transaction tr1 obtains the SalaryC collection and adds all bonifications. After each bonus is added, the objects is handed over to transaction tr2, which prints all
payment slips. 0
4.4.3 Implications
Supporting explicit concurrency has implications on other components of the DBMS and on the syntax of iDBPQL itself. We will look at the different types of simultaneous processing and outline their implications:
- Firstly, there is the INDEPENDENT DO statement that applies to sequences of iDBPQL statements inside a single transaction or, in the event t hat no transaction is defined, the entire evaluation plan. Since access to shared data must be from within a trans action, the latter case can be neglected since its evaluation will not involve the transaction management system (only local, non-shared data is accessed) . Consid ering the former case, the simultaneous execution only applies to operations within the same transaction. This, however, will not have implications for other DBMS components, in particular the transaction management system. According to the ACID principle, data consistency has to be preserved by each transaction, when run in isolation, and the programmer is responsible for ensuring this property.
- Secondly, there is the INDEPENDENT DO statement that results in the simultaneous execution of multiple transactions originating from the same evaluation plan, i.e. same main execution stream. From the transaction management system's point of view, these transactions are serialised as any other concurrent transactions (i.e. those discussed in Section 4.4. 1 ) . However, some syntactical constraints must be observed when using this type of explicit concurrency. Multi-threaded transactions must commit or abort before rejoining the main evaluation plan and synchronisation commands (i.e. WAIT statements) must not form cyclic waiting conditions.
4.5. EXAMPLES Markus Kirchberg
- Thirdly, there is the CONCURRENT DO statement that applies to operations on col lections either across transactions, within a single transaction or, in case no trans action is defined, the entire evaluation plan. Operations are synchronised implicitly by pipelining objects that the first operation has released to the second operation etc. Thus, concurrent access to the same collection object is enabled while access to the collection members is synchronised. This form of cooperation is different from the modes of processing traditional DBMSs usually perform. As a consequence, the transaction management system must not be only able to distinguish serial and independent (i.e. of operations allowing shared access or operations operating on unrelated objects) execution of operations within the same transaction but also the coordinated execution of possibly conflicting operations on the same collection. Corresponding extensions to transaction models and correctness criteria are pro posed in [6] . The suggested transaction model distinguishes between two partial orderings, which are weak order (i.e. data flow takes place through DBS objects) and strong order (i.e. external flow of information b etween operations or transac tions) . While the former enables simul tan eo us processing, the latter implies serial execution. The corresponding correctness criteria, stack-conflict consistency, per mits parallel execution of weakly ordered operations given that their serialisation graph is preserved.
While the support of explicit simultaneous execution requires a more sophisticated transaction management system, it offers the potential to significantly increase system performance. For instance, assume that we have two subsequent operations accessing the same collection. This collection may be of a size that does not fit into the avail able main memory. Serial evaluation is likely to result in two consecutive scans, which degrades system performance. On the contrary, the CONCURRENT DO block enables the evaluation of both operations with one scan.
4 . 5 Examples
EXAMPLE 4 . 2 5 . First, we will consider a very simple request that does not involve the run-time or DBS metadata catalogues nor does it invoke any other evaluation plan during its execution. The popular 'Hello world!' example can be formulated in iDBPQL as follows:
0 1 EVALPLAN HelloWorld ( VOID ) STRING { 02 RETURN ( " Hello world ! " ) ;
0 3 }
The only metadata reference that is associated with this evaluation plan identifies the
argument of the RETURN statement as a STRING value. D
While this first example does not have any associated metadata catalogue references, the majority of evaluation plans do. In iDBPQL, one can code requests that do not involve any persistent data, use persistence only to keep track of the state of objects (e.g. a user's profile) or take full advantage of the integrated processing and querying capabilities on non-shared transient and shared persistent objects. While the former
4.5. EXAMPLES Markus Kirchberg two usages correspond to more traditional PL programs, the latter utilises advantages that result from the integration of DBS languages and OOPLs. While the next Example 4.26 only outlines a more complete specification of one particular class of the university application , Example 4.27 contains a few transient requests that access this schema. EXAMPLE 4 . 2 6 . As a second example, we outline the behaviour specification of a class
definition in a database schema. In fact, we will continue Example 4 . 1 7 and refine the definition of class EnrolmentCcc · Behaviour specifications are added and their corresponding evaluation plans are proposed.
First, let us consider the extended EnrolmentCcc class definition: 01 CLASSDEF EnrolmentCcc { 02 STRUCTURE { 03 04 05 06 07 LectureCcc lecture ; StudentC student ; READONLY EnrolmentT ; } //
// the date v a l u e can b e vi ewed from the outside of this c l ass but the s ame does no t ho l d for modifi cations 08 BEHAVIOUR {
09 10 1 1
PRIVATE checkCrsPreRequisites ( VOID ) : BOOLEAN ; verifyEnrolment ( VOI D ) : BOOLEAN ;
EnrolmentCcc ( LectureCcc lect , StudentC std ) ; / / o b j e c t c ons tructor
12 } 13 14 1 5 1 6 CONSTRAINT {
UNIQUE ( lecture , student ) ;
}
/1 uniqueness constraint
17 }
For each behaviour specification, there exists an associated evaluation plan, which has the same modifiers, name and arguments as the behaviour specification. We will con sider corresponding evaluation plans next:
First, let us consider the evaluation plan that describes the implementation on the
verifyEnro lment method:
20 EVALPLAN verifyEnrolment ( VOID ) : BOOLEAN {
2 1 / / check whe ther o r n o t t h e s tudent has already comp l e t e d the 22 // corresponding cours e successfu l ly
23 I F ( EXI STS ( RecordC WHERE ( ( THIS . student == student ) &&
24 ( THI S . lecture . course == course ) ) ) 25 ( result . isValueOf ( PassGradesT ) ) ) {
26 / / the s tudent already has comp l e t e d the cours e successfu l l y 2 7 RETURN ( FALSE ) ;
28 }
29
30 / / check whe ther or no t the s tudent m e e t s a l l c ourse pre-requis i t es
3 1 IF ( ! checkCrsPreRequisites ( VOID ) ) {
32 / / at l eas t one pre-requi s i t e i s not met
33 RETURN ( FALSE ) ;
34 }
4.5. EXAMPLES
36 // a L L pre-requ i s i t es are me t
37 RETURN ( TRUE ) ;