An Infrastructure For Cooperative Applications Based On Conventional Database Transactions Norbert Ritter Department of Computer Science University of Kaiserslautern P.O.Box 3049 , 67653 Kaiserslautern , Germany e-mail : ritter@informatik.uni-kl.de Abstract ? Computer-Supported Cooperative Work ? -LRB- CSCW -RRB- is a young , interdisciplinary research area considering applications with strong demands on multiple fields of computer technology , e.g. , distributed systems and networks , or multi-media systems . In this paper , we will be focusing on the information-sharing aspect and the corresponding activity-control aspect . Employing database systems for the management of shared data means dealing with conventional transactions . Crucial issues of the classical transaction concept are the isolated execution and the underlying notion of consistency . Whereas consistency support is necessary for any multi-user application , strict isolation seems to contradict the cooperation issue -LRB- release of preliminary data -RRB- . As a consequence , the transaction concept plays a key role due to consistency management , but cooperation control must be supported by additional facilities . Therefore , we exploit the classical transaction as the basic operational unit in the infrastructure we propose for cooperative applications . Transactions are well suited for the execution of the elementary actions into which the work of a cooperating user can be decomposed . Beside these elementary actions , further types of activities can be observed in cooperative work arrangements . In order to give a comprehensive activity support , our infrastructure provides several abstractional layers : classical transactions , version manipulations , tool invocations , workflow executions and explicit cooperation control actions . Multiple possibilities of interplay between these layers make this infrastructure feasible to different classes of cooperative applications . 1 . Introduction The term groupware systems -LSB- Gr94 -RSB- usually refers to a huge class of computer systems which can not be rigidly distinguished from other classes of computer systems . In -LSB- EGR91 -RSB- groupware is defined as : ? Computer-based systems that support groups of people engaged in a common task -LRB- or goal -RRB- and that provide an interface to a shared environment . ? Being engaged in a common task -LRB- or goal -RRB- mostly means working on shared resources -LSB- GS87 -RSB- . Simultaneous operations on shared data cause conflicts which need to be resolved by appropriate concurrency-control techniques . Here , major parts of the CSCW community see a philosophical difference between database systems and groupware systems . The reason is the isolation property which is one of the important characteristics of conventional transactions . These characteristics are often called the ACID-properties -LRB- atomicity , consistency , isolation , durability -RRB- -LSB- HR83 , GR93 -RSB- . Beside isolation , the consistency property is a crucial issue . It means that a transaction is an operational unit of consistency . Often it is necessary to perform several database operations in order to move the database from one consistent state to another consistent state . In our opinion this notion of consistency is of a very basic nature and has to be the foundation for cooperation , too . Therefore , it should also be applied in cooperative work arrangements employing shared information repositories . For example , in cooperative design-applications , e.g. , mechanical or electronic design , there is mostly no need for a design tool to cooperate directly with other tools . Nevertheless , it is definitely important for two designers , each working on a certain part of the overall design task , to cooperatively exchange information about the -LRB- preliminary -RRB- design-object version -LRB- e.g. , a software module -RRB- created by the design-tool application -LSB- Ri94 -RSB- . Another example can be found in group editing -LSB- EGR90 -RSB- . It is often necessary to isolate the writing/modification of a word/sentence in order to perform a semantically consistent modification of the contents . In this example the need for flexible transaction boundaries becomes obvious ; yet atomic and isolated units of changes are to be supported due to consistency requirements . Therefore , we think that transactions are well suited for the most elementary actions performed by cooperating users . Additionally , further types of activities must be supported , e.g. , - version manipulations , esp . needed in cooperative design applications , - application-tool executions , - workflow-executions for those parts of cooperative work which are well-ordered and can be pre-planned , and - control of a free , dynamic cooperation . Regarding the different types of activities naturally predominating in groupware applications , we can summarize that neither a single conventional ACID transaction is the appropriate unit of a cooperating user?s work , nor the result of each database operation initiated by this user is a reasonable portion of cooperative data exchange . Therefore , we have to develop an adequate infrastructure allowing to map all kinds of activities occurring in groupware applications to operational units manipulating shared data . In the following section , we will outline , why we do not apply one of the many cooperative transaction models proposed in the literature . Sect. 3 gives an overview of the CONCORD model -LRB- CONtrolling COopeRation in Design environments -RRB- , we proposed for design applications and which is the foundation of designing the generalized infrastructure outlined in Sect. 4 . The last section gives a conclusion . 2 . Cooperative Transactions Serializability is the notion of correctness for conventional transactions -LSB- HR83 -RSB- . It allows concurrently running transactions to interleave their data-manipulation operations however obeying the restriction that the effect of the schedule resulting from the interleaving has to be the same as the effect of an arbitrary serial schedule . This correctness criterion is well-founded and well understood -LSB- BSW79 -RSB- . Lots of concurrency-control techniques which were proven to enforce serializability have been proposed during the last decade . An example is the strict two-phase locking-protocol -LSB- GR93 -RSB- which is applied very often . Serializability asserts semantically consistent database-state transitions . We claim that in almost any application area there are atomic units of work consisting of sequences of database operations which are to be performed completely in order to make the manipulated data usable at all . On the other hand , it is easy to see that a single conventional transaction can not carry the entire sequence of actions performed by a cooperating user because serializability is too restrictive . This led the database community to develop cooperative transaction models . -LSB- El92 -RSB- gives a good overview of advanced transaction models including models with cooperative capabilities . The most promising approach to cooperative transactions is to extend the class of serializable schedules by further schedules reflecting the patterns of cooperation predominating in the considered application . Examples are the models proposed in -LSB- NZ92 -RSB- and -LSB- ABEK94 -RSB- . Due to space restrictions , we just want to outline the ? cooperative transaction hierarchies ? approach -LSB- NZ92 -RSB- . Here , the specification of user-defined correctness criteria is supported . Cooperating transactions are introduced which can be combined to transaction groups which , in turn , can be nested . A local database is associated to every node of this hierarchy which is manipulated by the node?s direct sub-nodes . These manipulations are synchronized by means of semantic patterns reflecting local , user-defined correctness criteria which can be implemented as deterministic , finite automata accepting sequences of operations preserving data consistency . This approach provides very powerful and flexible mechanisms for specifying user-defined correctness criteria which can be changed and supplemented dynamically . It also shows a mature formal foundation . However , a lot of specification work has to be done , and the patterns of interactions must be known in advance in order to specify the correctness criteria for the transaction level . In our opinion , it is very difficult to do this specification work for two reasons . First , in many cases , the patterns of cooperation can not be determined exactly in advance . Second , even in cases the patterns are known , it is hard to express them in terms of database objects and data-manipulation operations , because the latter belong to a very technical level of activity management , while cooperation is easier to express in terms of more abstract activities . There are several types of activities to be managed in between database operations/transactions and the operational unit representing the work of a group of cooperating users . For these reasons , we have chosen another approach to providing an infrastructure for cooperative applications , as described in the following sections . 3 . Overview of the CONCORD Model Before discussing our general activity-support framework -LRB- in Sect. 4 -RRB- , we will first give an overview of our CONCORD model -LSB- Ri94 -RSB- which was originally developed to support design applications , e.g. , electronic design . The concepts of the infrastructure we will describe in Sect. 4 are based on the CONCORD model . The CONCORD model -LSB- Ri94 -RSB- captures the dynamics inherent to design processes . To reflect the different requirements , such as hierarchical refinement , goal orientation , stepwise improvement and team orientation , three different levels of abstraction are distinguished as illustrated in Fig. 2 . Administration/Cooperation Level -LRB- AC level -RRB- At the highest level of abstraction , we consider the more creative and administrative part of design work . There , the focus is on the description and delegation of design tasks as well as on a controlled cooperation among the design tasks . The central concept at this level is the design activity -LRB- DA -RRB- . A DA is the operational unit representing a particular design task or subtask . During the design process , a DA hierarchy can be dynamically constructed resembling -LRB- a hierarchy of -RRB- concurrently active tasks . All relationships between DAs are explicitly modeled , thus capturing task-splitting -LRB- cooperation-relationship delegation -RRB- , exchange of design data -LRB- cooperation-relationship usage -RRB- , and negotiation of design goals -LRB- cooperation-relationship negotiation -RRB- . Design-Control Level -LRB- DC level -RRB- Looking inside a DA reveals the DC level . There , the organization of the particular actions performed in order to fulfill a certain -LRB- partial -RRB- design task is the subject of consideration -LRB- work flow -RRB- . Fig. 2 shows at this level an execution plan -LRB- script -RRB- of a particular design activity . This script models the control/data flow between several design-tool executions . Fig. 2 : Abstraction levels of the CONCORD model Advanced DBMS -LRB- object and version management -RRB- save suspend resume restore checkout1 checkout2 checkin DOP1 DOP2 DOP4 DOP5 Evaluate ... . Design Operation DOP3 control/data flow delegation negotiation usage Administration/Cooperation Level Design Control Level Tool Execution Level Design Activity cooperation relationships DA6DA5DA4 DA2 DA3 DA1 -LRB- DA -RRB- -LRB- DOP -RRB- The operational unit serving for the execution of a design tool is the design operation -LRB- DOP -RRB- . In order to control the actions within the scope of one DA , but without restricting the designers ? creativity , flexible mechanisms for specifying the workflow for a DA -LRB- scripts , constraints , event-condition-action rules -RRB- are provided . Due to space restrictions , we can not detail this layer and refer to the literature -LSB- DE93 -RSB- . Tool-Execution Level -LRB- TE level -RRB- From the viewpoint of the DBMS or data repository , a DOP is a long transaction . A DOP has the consistency , isolation and durability properties of conventional transactions but is not atomic . Because of long duration , it is internally structured by save/restore and suspend/resume facilities as illustrated in Fig. 2 . A DOP processes design-object versions in three steps . First , the input versions are checked out from the integrated data repository . Second , the loaded object data is processed by the design tool . Third , the finally derived new versions are propagated back to the data repository -LRB- checkin operation -RRB- . Considering that DOPs process versions , the isolation property does not require blocking1 . The three mentioned abstractional layers are provided on top of an object and version management system consisting of an object-oriented database management system and an additional version-management layer -LSB- KS92 -RSB- . The latter provides explicit versions of complex-structured objects . Thus , the checkout/checkin operations issued by long transactions at the TE level are mapped onto short , conventional database transactions by the version-management system . Summing up , the CONCORD processing model provides user-centered cooperation control facilities -LRB- AC level -RRB- on top of workflow-management primitives -LRB- DC level -RRB- , such that preliminary information created by workflows can be subject of cooperation . The actions constituting a workflow -LRB- e.g. , design tool applications -RRB- , in turn , are themselves long transactions -LRB- TE level -RRB- manipulating versioned data . Version manipulations -LRB- version-management layer -RRB- are performed by means of checkout/checkin operations which are realized as short ACID transactions -LRB- database management system -RRB- . For further details concerning the CONCORD model we have to refer to -LSB- Ri94 -RSB- . 4 . An Infrastructure for Cooperative Work Although the CONCORD model has been developed to support design applications. , we claim that major principles of this approach are also applicable in other areas of cooperative applications . Therefore , the discussion in this subsection is not limited to design applications . First we will outline , how the CONCORD processing-layers can be generalized towards an infrastructure supporting cooperative applications . Thereafter , we will discuss the processing layers of the generalized model in more detail . 4.1 Generalization of the CONCORD Layers Fig. 3 shows five abstractional layers giving comprehensive activity-management support as well as activity-control support for those cooperative applications relying on shared data repositories . We will outline these layers in a bottom up manner and will shortly discuss the multiple possibilities of interplay indicated by the arrows in Fig. 3 . At level 1 ACID transactions are managed . The traditional transaction concept asserts basic consistency , which is also required in cooperative applications to support the interleaving of the most elementary , data manipulating actions performed by cooperating users . Level 2 provides long transactions which are only acceptable in cooperative work arrangements if the underlying data management supports explicit versioning . For example , in mechanical or electronic design versioning and configuration concepts can effectively be used to describe preliminary and final design-object states . Furthermore , mutual blocking of typically long running design tools is avoided , because concurrent tools can derive different successors of the same input version . Assuming , the version management system is realized on top of an object-oriented DBMS , the checkout/checkin operations of the long transactions must be mapped onto ACID transactions -LRB- level 2 ? level 1 -RRB- . Due to flexibility of tool implementation and tool integration , a separate level for application-tool invocations , level 3 , is provided . On one hand , a tool execution can be mapped onto one -LRB- or even several -RRB- long transaction -LRB- s -RRB- -LRB- level 3 ? level 2 -RRB- ; on the other hand , it can directly be mapped onto -LRB- one or -RRB- a number of short transactions -LRB- level 3 ? level 1 -RRB- . 1 . Several successors of a single version can be derived by concurrent DOPs . Updating a version , on the contrary , requires locking it for the entire DOP duration . For a subclass of cooperative applications the actions -LRB- tool applications or more abstract activities -RRB- performed by a single cooperating user or even the entire group can be pre-planned . In these cases a workflow description can be specified . The execution of such a workflow is the task of level 4 . Usually , the elementary actions contained in a workflow are applications of tools or of special functions offered by tools -LRB- level 4 ? level 3 -RRB- . In most cases , however , cooperation can not be pre-planned , because of its dynamic nature , or a free cooperation must be supported in addition to workflow specifications -LRB- see Sect. 3 -RRB- . In terms of data management this matter concerns the exchange of information between concurrently active , application-oriented operational units2 . Management of these units and control of their cooperation is done by means of the concepts provided on level 5 . The internal structure of a cooperative , operational unit can in some cases be pre-specified within a workflow description -LRB- level 5 ? level 4 -RRB- , in other cases it must be established dynamically by directly invoking tools during runtime -LRB- level 5 ? level 3 -RRB- . After this brief introduction of the layers supported by our DBMS-based infrastructure for cooperative applications we will detail the concepts of each layer by considering the operations provided at the layer?s interface . 4.2 Major Concepts , Interfaces and Interplay Fig. 4 shows the types of operational units managed at the different levels of the generalized model and gives a further impression of the possibilities of interplay . In this section we have chosen a top down description to clarify the several possibilities of breaking down application-specific , cooperative processing-units to the more technical database transactions . Level 5 : Cooperation Control Due to independence from the application subclass we will talk no longer about design activities -LRB- DA -RRB- -LRB- see Sect. 3 -RRB- but about cooperative activities -LRB- CA -RRB- . A CA is created by the operation Create_CA -LRB- super_CA_ID , users -RRB- : CA_ID . The users parameter fixes the users3 which will be allowed to initiate and perform actions associated to this CA . The optional parameter super_CA_ID establishes a super_CA-sub_CA relationship4 . After its creation , the CA?s users can start working in the context of the CA . There are two possibilities to organize this work local to a CA . First , the execution of a script , as we call a workflow description , can be executed -LRB- level 5 ? level 4 -RRB- , allowing high control but low flexibility and is , therefore , only applicable in restricted application areas . Second , the functionality offered by application tools can be employed in a dynamic way by directly calling the level-3 interface -LRB- level 5 ? level 3 -RRB- . The latter way offers less control but a higher flexibility . Independent from this internal structure of a CA , all results of the transactions , onto which the tool applications are mapped , become visible to all users of the same CA . To support cooperation between CAs the selective pre-release of information is supported by the following two operations . 2 . At this level , we consider the sequence of actions performed by a single cooperating user or the set of actions performed by a group of users , respectively , as an application-oriented operational unit . 3 . Depending on the special application case , single-user and/or multi-user CAs can be appropriate . The users of a multi-user CA cooperate closely with each other and cooperate in a more loose manner with other CAs -LRB- cf. cooperation facilities -RRB- . 4 . When a sub_CA is terminated all its rights on database objects migrate to the super_CA . Fig. 3 : Generalization of the abstractional layers Cooperation Control Workflow Management Long-Transaction Management ACID-Transaction Management Tool-Invocation Level 5 Level 4 Level 3 Level 2 Level 1 Permit -LRB- permitting_CA_ID , set_of_receiving_CA_IDs , set_of_objects , right -RRB- . By issuing this operation , the CA indicated by parameter permitting_CA_ID permits cooperating CAs -LRB- specified by parameter set_of_receiving_CA_IDs -RRB- to manipulate the database objects in set_of_objects in a way restricted by parameter right . To permit access to all its objects , the permitting CA can invoke the permit operation with an empty set of objects . In the generalized model , right can be read , write or derive , depending on the set of layers utilized . The set of objects can also be specified implicitly by referring to a tool application , so that all its results are pre-released . Delegate -LRB- delegating_CA_ID , set_of_receiving_CA_IDs , set_of_objects -RRB- . This operation causes a complete transmission of all rights , the delegating CA has on the indicated objects , to the receiving CAs . Again , the set of objects can implicitly be specified -LRB- delegating all objects manipulated by a tool application -RRB- or can be empty , to delegate all objects the delegating CA has been working on . The operations mentioned so far are best suited to express the character of explicit cooperation control . Nevertheless , further operations are needed . For example , it must be possible to terminate a CA -LRB- operation Terminate_CA -RRB- . This operation should only be carried out , if there is no more active script execution or tool application within the scope of the CA . Further operations are needed , making data exchange more comfortable , e.g. , initiating the scope of objects accessible by a CA , maintaining conditioned data requests between CAs , supporting other ways of cooperation , e.g. goal specifications and negotiations , or providing facilities for notifying users after certain activities of cooperating users / CAs5 . Level 4 : Workflow Management Due to space restrictions , we can not go into the multiple possibilities of specifying workflows , reaching from petri nets to rule sets -LSB- Br93 , Ja93 -RSB- . Assume , a script arranges invocations of tools , which are integrated into our framework , within data flow and control flow descriptions . In the case of multiple-user CAs , the script also can contain role and policy management specifications . The major operations offered at the interface of level 4 contain those to start -LRB- operation Start_Script_Execution -RRB- the execution of a given script and to cancel -LRB- operation Cancel_Script_Execution -RRB- a running script . Furthermore , a running script can be suspended -LRB- operation Suspend_Script_Execution -RRB- by a user of the according CA . Calling this operation , we can decide for each currently active tool , whether it shall also be suspended , if possible , or suspension shall be deferred until its normal termination , or it shall be aborted . A suspended script execution 5 . To support notification services the concepts of active database systems -LSB- RIDE94 -RSB- are well suited . CAi CAj CAl CAn Script-Execution Tooli - Toolj - Tooll - ToollInvocation Invocation Invocation Invocation ... . LTAl LTAn ... ... TAn TAj ... TAi TAl Level 5 Level 4 Level 3 Level 2 Level 1 Fig. 4 : Interplay of the abstractional layers can be resumed by calling the operation Resume_Script_Execution . This shows the non-atomic character of the script execution . After every break -LRB- system failure or user-initiated suspend -RRB- , the system component responsible for the script execution saves the context of the youngest , consistent state in order to provide a forward-oriented continuation . Level 3 : Tool Invocation6 As already mentioned , this layer is introduced to give the user an easier mental model of the processing structures in the system . For that reason , he can only see the application-oriented levels 5 to 3 , while the more technical layers 1 and 2 are hidden . The integrated tools can be invoked by the operation Start_Tool_Execution -LRB- Tool_Id -RRB- . This operation can be called by the script-executing system -LRB- level 4 ? level 3 -RRB- or directly by the user -LRB- level 5 ? level 3 -RRB- . Every further operation available at the interface of level 3 depends on the functionality of the invoked integrated tools . It is the task of tool-integration services and of the tool implementor to hide the internal structure of the tool -LRB- level 3 ? level 2 or level 3 ? level 1 -RRB- from the user . Level 2 : Long-Transaction Management In the previous section , we emphasized that long transactions are only applicable in cooperative work arrangements , if they are working on versioned data , because otherwise mutual blocking would lead to unacceptable performance . The boundaries of a long transaction can be set by the operations Begin_Of_Long_Transaction and End_Of _ - Long_Transaction . Beside the traditional abort operation -LRB- Abort_Long_Transaction -RRB- save/restore facilities -LRB- operations Save_Context , Restore_Save_Point -RRB- must be supported due to long duration . Further desirable operations are Suspend_Long_Transaction and Resume_Long_Transaction which are relying on the same mechanisms as the save/restore facilities allowing to save and reactivate the processing contexts of certain processing states . Regarding versioning , synchronizing long transactions becomes quite easy . Generally , the concurrent derivation of several successors of the same input version does not lead to any conflicts . In spite of that , it can be necessary to prevent parallel derivations from the same input version for application-specific reasons . Here , as well as in the case of version updates -LRB- which occur very seldom -RRB- blocking is required . In order to avoid an unreasonably long waiting situation , which can be expected whenever a checkout operation can not receive the required read or derivation lock , this situation is reported to level 3 . This allows the tool implementor to foresee appropriate contingency actions . Level 1 : Short-Transaction Management ACID transactions are used to execute the ckeckin/checkout operations of long transactions -LRB- level 2 ? level 1 -RRB- or to directly map functions offered by tools -LRB- level 3 ? level 1 -RRB- . The usual operations of transaction processing -LRB- e.g. Begin_Of_Transaction , Abort_Transaction , End_Of_Transaction -RRB- -LSB- GR93 -RSB- are offered at the interface of level 1 . Upward inheritance of locks All concurrently active , short transactions -LRB- no matter to which CA they belong -RRB- are performed in isolation . Suppose , serializability is enforced by the strict two-phase locking-protocol . At the successful end of a transaction its locks are not released but upward inherited through the utilized layers to the corresponding CA . This implies , that modified data is , at first , only visible to users of the same CA and still locked for different CAs . Cooperation between CAs is to be managed at the cooperation-control level -LRB- level 5 -RRB- by using the primitives offered at its interface . Because of lock inheritance we have to consider the case that a transaction requires a lock held by a different CA . In this case the transaction can not be blocked , because CAs are expected to have a long system residence time . Here , notification facilities are to be provided . The user who issued that transaction needs to be notified about which objects , for which his transaction can not be granted the acquired lock , are locked by which CA in which mode7 . This information can help the user to take up cooperation with the according CA . 6 . Remark to level 3 in Fig. 4 : The picture might cause the impression that those tools , which can be directly invoked from level 5 must be directly mapped to level 1 ; this is not true ; tool invocation is completely independent from the tools ? internal structure . 7 . To read a data item a transaction only needs a shared lock allowing the lock-holding transaction and concurrently active transactions to only read and not write it . To write a data item a transaction needs to get an exclusive lock -LSB- GR93 -RSB- . Example : Group Editor -LRB- Level 5 ? Level 3 ? Level 1 -RRB- Design applications , for which the CONCORD model has been developed , require all activity levels , as shown in -LSB- Ri94 -RSB- . Other kinds of cooperative work-arrangements do not require all levels . An application scenario where the direct interplay of the cooperation-control layer -LRB- level 5 -RRB- , the tool-invocation layer -LRB- level 3 -RRB- and the transaction-management layer -LRB- level 1 -RRB- suffices , is a group editor -LSB- EGR90 -RSB- . Suppose words , sentences , paragraphs , pages , sections , etc. , to be the data granules which are manipulated by transactions . Group work can be organized by initiating single-user and/or multi-user CAs . Writing a text fragment is mapped by the editor tool to a transaction , and after having finished a semantically meaningful text fragment the current transaction is terminated , and the modifications become visible to the other users of the CA . Additionally , read or write permissions can be granted dynamically to the users of cooperating CAs . To modify text the user has to issue an update-transaction -LRB- via the editor tool -RRB- which reads the text fragment which is semantically affected by the modification . This requires an exclusive lock . It can not be granted if one of the following situations exists . First , a concurrent transaction , issued by a user of the same CA , keeps locks on parts of the text . Second , a concurrent transaction , issued by a user of a different CA , keeps locks on parts of the text , but granted permission previously . Third , a different CA keeps locks on parts of the text and did not grant permissions . In the first two cases the user has to wait -LRB- his transaction is blocked for a predictable short duration -RRB- until the semantically atomic set of modifications issued by the cooperating user is completed . Then he has to read the modified text again and to decide whether his intended modifications are still reasonable or not . In the third case the user can be notified that cooperation facilities must be applied before the text fragment can be accessed . This example shows that due to consistency purposes it is appropriate to manipulate text by issuing transactions -LRB- semantically correct modifications -RRB- . It is necessary to isolate those parts of the text whose semantics are potentially affected by modifications . It doesn?t make sense to let users concurrently modify a text fragment , if modifications of one user change the contents of the complete fragment . 5 . Conclusions In this short position paper , we proposed a comprehensive infrastructure for activity-support in cooperative work arrangements . The concepts were achieved by generalizing the ideas of the CONCORD model , which has been proposed to support cooperative design applications . The argumentation for applying traditional transactions also in groupware applications is the consistency aspect . Elementary actions performed by cooperating users usually consist of several database operations . Due to consistency , this sequence of operations must be performed completely or not at all . Only the results of these elementary actions are reasonable granules of cooperation . Obviously , the entire set of actions performed by a cooperating user can?t be performed within a single ACID transaction . There are several further types of activities which must be assigned to distinct abstractional layers in order to separate the application-oriented activity layers from the more technical layers and , thereby , allow the user to build up a more natural , mental model of the operational units managed by the system . Considering the inherent dynamics of groupware applications and the required flexibility , we decided to provide explicit cooperation-control facilities at the system interface . Workflow management facilities can be utilized optionally . A tool-invocation layer separates application-oriented and cooperation-based layers from technical transaction-oriented layers . The latter exploit approved traditional concepts because advanced , cooperative transaction models do not consider the multiple types of activities to be supported . Since almost all kinds of cooperative applications rely on shared data , we view this approach as an important contribution . In order to provide a user-centered approach to cooperation control , the following two aspects should be further explored . First , flexible application tools must be developed that are not implemented as a single implicit transaction , but guide the user to flexibly partition the tool execution into several short transactions during runtime . This allows to make meaningful processing states dynamically visible to cooperating users . Second , dynamic locking granules are needed as shown in the group editor example . It should be possible to lock exactly the amount of data which is semantically affected by the intended modifications . Acknowledgments I would like to thank Bernhard Mitschang and Joachim Thomas for their helpful comments on this paper . Literature ABEK94 Agrawal , D. ; Bruno , J.L. ; El Abbadi , A. ; Krishnaswamy , V. : Relative Serializability : An Approach for Relaxing the Atomicity of Transactions ; Proc . ACM SIGACT/SIGMOD Symposium on Principles of Database Systems , May 1994 . Br93 Brettschneider , F. : A Process Model for Design Flow Management and Planning , Fortschritt-Berichte VDI , Reihe 9 ; Elektronik , Nr , 157 , VDI-Verlag , D?sseldorf , 1993 . BSW79 Bernstein , P.A. ; Shipman , D.W. ; Wong , W.S. : Formal Aspects of Serializability in Database Concurrency Control ; IEEE Transactions on Software Engineering ; Vol 5 ; No. 5 ; May 1979 , pp. 203-216 . DE93 Bulletin of the Technical Committee on Data Engineering , Special Issue on Workflow and Extended Transaction Management , IEEE Computer Society , June 1993 , Vol . 16 , No. 2 . EGR91 Ellis , C.A. ; Gibbs , S.J. ; Rein , G.L. : Groupware - Some Issues and Experiences , Communications of the ACM , Vol . 34 , No. 1 , Jan. 1991 , pp. 38-58 . EGR90 Ellis , C.A. ; Gibbs , S.J. ; Rein , G.L. : Design and use of a group editor ; Engineering for Human Computer Interaction ; Cockton , G. , Ed. ; North Holland , Amsterdam ; 1990 ; pp 13-25 . El92 Elmagarmid , A. -LRB- ed . -RRB- : Transaction Models for Advanced Database Applications , Morgan Kaufmann , San Mateo , CA , 1992 . GR93 Gray , J. , Reuter , A. : Transaction Processing : Concepts and Techniques , Morgan Kaufmann Publ. , San Mateo , CA , 1993 . GS87 Greif , I. ; Sarin , S. : Data Sharing in Group Work , in : ACM Transactions on Office Information Systems , Vol . 5 , No. 2 , 1987 , pp . 187-211 . Gr94 Grudin , J. : Computer-Supported Cooperative Work : History and Focus , IEEE Computer , May 1994 , Vol . 27 , No. 5 , pp. 19-26 . HR83 H?rder , T. , Reuter , A. : Principles of Transaction-Oriented Database Recovery . ACM Computing Surveys 15 , 4 , 1983 , pp. 287-318 . Ja93 Jablonski , S. : Transaction Support for Activity Management ; in : Proc . Workshop on High Performance Transaction Processing Systems , Asilomar , CA , Sept. 1993 KS92 K?fer , W. ; Sch?ning , H. : Mapping a Version Model to a Complex Object Data Model , Proc . of the 8th Int . Conf . on Data Engineering , Tempe , Arizona , 1992 . NZ92 Nodine , M.H. ; Zdonik , B. : Cooperative Transaction Hierarchies : Transaction Support for Design Applications ; VLDB Journal 1 , 1992 , pp . 41-80 . RB91 Rodden , T. ; Blair , G. : CSCW and Distributed Systems : The Problem of Control , in : Proc . 2nd European Conference on Computer-Supported Cooperative Work , Sept. 25-27 , 1991 , Amsterdam , Netherlands RIDE94 Proc . 4th Int . Workshop on Research Issues in Data Engineering -LRB- RIDE -RRB- , Active Database Systems , February 14-15 , 1994 , Houston , Texas . Ri94 Ritter , N. ; Mitschang , B. ; H?rder , T. ; Gesmann , M. ; Sch?ning , H. : Capturing Design Dynamics - The CONCORD Approach ; Proc . 10th Int . IEEE Data Engineering Conference , Houston , Texas , Feb. 1994 , pp. 440-451 .

O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

activity support
concurrency control
cooperation control
transactions