Integrated Version and Transaction Group Model for Shared Engineering Databases

Transcription

1 Data & Knowledge Engineering Integrated Version and Transaction Group Model for Shared Engineering Databases D. Roller *, O. Eck, S. Dalakakis Institute für Informatik, Universität Stuttgart, Breitwiesenstr , Stuttgart, Germany Original research article Abstract Keywords: Shared engineering databases; Advanced transaction models; Cooperative product design; CAD concurrency control This paper presents a cooperative transaction model for shared engineering databases which provides a higher degree of concurrency and process parallelism in CAD. As opposed to traditional transaction models where intra-transaction results are isolated, the presented model allows exchanging and sharing of data and supports the integration of subresults into a common solution. The realization of the transaction system is based on concepts of active and object-oriented database systems. * Corresponding author. Tel ; fax: address: roller@informatik.uni-stuttgart.de (D. Roller) Copyright notice: This paper is to be published in "Data & Knowledge Engineerin, 42 (2002) ", Elsevier Science B.V. As a courtesy to the publisher, this paper may not be reproduced or distributed in any form.

2 Introduction Companies are enforced to improve their design process to maintain their position in the international market. Simultaneous engineering, cooperative work and distributed design teams are just some of the key factors in companies for the reduction of time to market and to achieve an improvement of product quality and reduced costs at the same time. Process parallelization and interdepartmental cooperations play an important role in current approaches to product development. A new process organization also requires new computer aided design (CAD) tools that do not just support individual design work but also the cooperation and coordination of parallel design activities. Shared engineering databases appear as a key technology for contemporary CAD software. In engineering environments, the database system is the component that represents shared data and regulates parallel accesses to it. The current state of a product design is represented by the state of the design database. Parallel work leads to different subresults that have to be integrated into a common solution. Even when designers are working on different components of the entire product, functional dependencies between these components cause that designers have to consider the results of colleagues in order to guarantee that their results are compatible. Here, a shared design database allows to integrate parallel design work and also provides a basis for communication and cooperation facilities. Requirements, CAD environments place to engineering database systems, differ from those of traditional database applications. The transaction model of traditional database systems is based on the concept of atomic transactions and serializable schedules. Parallel transactions are isolated by providing the illusion of working in isolation. Serializability, which is the main correctness criterion for concurrency control, requires that execution of a transaction as a single step that cannot be interrupted by other transactions. For that reason, serializability prohibits cooperation and data sharing among transactions. In contrast to the competitive situation in conventional database applications, the situation of cooperative product design is characterized by parties that are united by the superordinate goal of achieving a globally optimal solution [4]. Contemporary product design is characterized by design teams developing a product collaboratively. Since changes initiated by designers often interact with the work of colleagues, transactions want to see the results of parallel transactions and access shared data, knowing that this data may be incomplete and inconsistent. These intra-transaction interactions lead to definitively nonserializable schedules making the traditional transaction model not appropriate for engineering databases. While product data is not static but evolves across multiple representations over time, there may be no consistent state during the whole design process. Changes of a single design task often maintain only a partial consistency and a completely consistent state is often not seen during the whole design time. A division of parallel and cooperative design activities into single independent and isolated design steps is mostly not possible. The notion of a transaction as a logical and isolated unit of concurrency that leads a database from one consistent state to another is not appropriate in this context. Additionally, the serializability criterion is unnecessarily strong because nonserializable schedules provide much higher parallelism and better performance. Rather than the design product, the collaboration process should be subject of correctness. Besides concurrency control, the most important task of a design database system is recovery. The design process typically progresses by trial and error rather than in a linear way. When a traditional transaction fails, the database returns to the state before the whole transaction started. This total rollback is not a right recovery mechanism in CAD because of the lost design work. In design activities, a transaction is not an atomic unit of work that either succeeds as a whole or fails as a whole. A partial step back to previous states inside a long transaction is often more appropriate. A problem here is, that most recovery approaches to long transactions cannot be used because of the indeterminable and unpredictable characteristics of interactive CAD transactions. Most contemporary engineering environments use multi-copy approaches to coordinate parallel design work. These approaches are based on different copies of a design object for every design activity. Parallel design work is being done on these isolated copies and has to be merged later. These approaches are introduced to guarantee that designers do not invalidate the work of others. The process of merging different design copies, which is the main problem of these approaches, is mostly 2

3 not supported at all. Cooperative work arises only on a designer's own initiative without system support. Although CSCW tools (Computer Supported Cooperative Work), such as Shared Applications and Video Conferencing, are used more and more in current product design, these tools provide only rudimentary mechanisms to manage cooperative work on shared design objects. CSCW tools just provide means to manipulate data cooperatively but do not provide appropriate mechanisms to concentrate parallel design work towards the globally optimal solution and to coordinate communication and cooperation in the whole design process. The focus of this paper is to provide the basis for a new generation of cooperative CAD environments. The presented approach to an engineering database system does not only use knowledge based mechanisms to represent the semantics of product data but also uses this knowledge to support parallel and cooperative development of data more intelligently. Approaches to active and shared design databases are presented that increase the scope of database transactions to interactive and cooperative activities. Since design transactions are controlled by human persons, a transaction model for cooperative product design has to enhance communication and cooperation among its users. One objective is therefore to inform designers about the whole design process and the work of distributed design teams and to enable them to respond intelligently to certain problems. Active and interactive database mechanisms are used to signal when results of designers coincides, when new requirements are introduced, or when designers have to adapt their work to parallel results of colleagues. This paper presents a cooperative transaction model that takes into account the characteristics of cooperative product design. The whole transaction model consists of two submodels: a version model and a transaction group model. With regard to the cooperative situation in product design, both models do not intend to support atomicity and isolation of database transactions. The unit of concurrency control is not the transaction itself but single database objects. The presented models are developed especially for design databases and are only partly appropriate to conventional database applications. The main focus is to provide a high degree of concurrency and intra-transaction parallelism and to support cooperation and communication. Even if the formal correctness of the product is not enforced completely by these models, there is a good chance of supporting the design process more efficiently than traditional transaction models. Figure shows two-time table of the parallel design work of user and 2 working on the same product data. The shown time tables are exemplary and not subject of concrete measurements in practise. In time table A, the parallel work of the users is serialized. In time table B, the consequences of the cooperative transaction model is sketched. In this example, the design work of user is interrupted and a communication is being done with user 2. After this communication, the design work is done cooperatively. Since much consolidation is needed between user and 2 in this phase, the cooperative design work needs more time than the design work of a single user. But as the time tables make clear, the potential of parallel and cooperative work is much bigger than the overload of communication and consolidation of the users. The presented cooperative transaction model consists of a version and a transaction group model. The version model supports asynchronous workspaces among designers that work on multiple copies of the same design object. Temporary savepoints (also called versions in this context) split long transactions into several nonserializable steps that are used as a basis for interactive recovery mechanisms and information exchange facilities. Versions illustrate the life cycle of a design object and document the development process. Version modeling usually is defined as concepts suitable for structuring a database of complex engineering artifacts that evolve across multiple representations and over time and the operations through which such artifact descriptions are created and modified [3]. However, this paper does not present new approaches to version modeling in the sense of version and configuration management. Rather, savepoints are regarded as object version that can be used to make partly consistent subresults in long transactions accessible outside of transaction borders and to provide an interactive recovery mechanism for long transactions. Checkout/checkin mechanisms and savepoint operations are integrated to a set of new database operations that replace the traditional database primitives abort and commit. Rolling back an entire transaction is replaced by interactively restoring a defined savepoint. 3

4 Checkout Design Work Checkin Checkout Redesign Checkin A) User User 2 t Waiting for checkin of user Checkout Design Work Checkin Communication B) User User 2 Checkout Design Work Checkout Communication Communication Cooperative Design Work Cooperative Design Work Checkin Checkin Fig. : Comparing the productivity of parallel design activities The transaction group model provides a synchronous workspace by supporting cooperative data accesses to a single object copy. This model is defined by an external and an internal protocol. The external protocol grants cooperative accesses to shared data by group transactions. The responsibility for the consistency of data is partly transferred to the transactions that are able to use the provided facilities to coordinate their work. Instead of a consistency guarantee for single transactions, new consistency conditions for in progress design activities are provided in the internal protocol. In this protocol, mechanisms based on floor control impose several modes inside group transactions and make concurrency control more flexible and cooperative. Mechanisms based on floor control impose several modalities inside transaction groups and make concurrency control more flexible and cooperative. Since savepoints of the version model are realized as regular database objects, cooperative accesses are granted even to savepoints. That means that the transaction group model and the version model cannot be regarded separated from each other but appear as an integrated transaction concept that supports synchronous and asynchronous cooperations for collaborative design activities. The overall approach to an integrated version and transaction group model combines both methods and applies the mechanisms of group transactions even to the version model. 2 Related work While the problem of coordinating concurrent accesses to conventional databases has been thoroughly studied, there exist only few studies about concurrency control in cooperative design environments. The special requirements of these environments are already published and the fact that the traditional transaction model is not appropriate for CAD transactions is recognized [5] [26]. The most commonly used protocol in traditional database systems is two-phase locking [0]. [5] gives a small survey of traditional approaches to concurrency control. An approach to granularity locking in a shared database is given in [25]. Grays approach aims to minimize the number of locks 4

5 by introducing additional lock modes besides the conventional share and exclusive mode. The term granularity refers to the size of objects that can be locked. Using these additional lock modes, objects of coarse granularity can be locked as well as fine granularity. A coarse granularity has the advantage of fewer locks and the disadvantage of less concurrency. Nested transactions [4] are a composition of a set of subtransactions which can themselves be nested transactions. This concept introduces a control structure consisting of a hierarchy of subtransactions that offers modularity and a finer grained concurrency. One class of solutions to concurrency control in design environments deals with supporting long transactions. This problem has been well studied because it does not only occur in design applications but also in many other traditional domains. Most of its solutions work by splitting up long transactions into shorter steps. After each step, other transaction is able to access the used data. Parts of these solutions extend serializability-based techniques while others relax serializability of schedules. If a transaction accesses data in a known way, this knowledge can be used to provide higher parallelism and better performance. Altruistic locking [6] is an approach that guarantees serialization by using access patterns which are information about the interactions of transactions with the database. Transactions are able to release their locks early and transactions that access this released data are said to run in the wake of this transaction. Altruistic locking provides a third concurrency control operation, called Donate, in addition to Lock and Unlock and places restrictions on transactions that accept donations, i.e. that access donated objects. [] investigates how the semantic knowledge of an application can be used in a distributed database to process transactions efficiently and to avoid some of the delays associated with failures. Serializability constraints are replaced by less restrictive semantic consistency constraints. The transaction processing mechanism receives some help from the users of the system, e.g. by grouping actions of transactions into steps or by providing countersteps or compensating steps to back out transactions. Another correctness criterion for processing transactions in advanced database applications is presented in [6]. In [23], the concept of sagas is introduced to alleviate the problem of long transactions by relaxing the serializability requirement. A long transaction is a saga if it can be written as a sequence of subtransactions that can be interleaved in any way with other transactions. Each subtransaction has to be provided with a compensating transaction that undoes from a semantic point of view any of its actions. Compensating transactions are used to amend a partial execution of a saga when it cannot completed successfully. [2] introduces a new formalization for the concurrency control problem when semantic information is available about a transaction. This approach exploits the semantic information available about the transactions to allow controlled nonserializable interleavings. The semantic information takes the form of transaction types, transaction steps, and transaction breakpoints. Besides compensating transactions, the concept of savepoints was developed to recover databases. [] gives a small survey about this recovery technique. Savepoints are used to save a state of a database and to provide a partial rollback to this state. In contrast to compensating transactions that are used to undo actions of transactions, all updates of parallel transactions are lost when a previous state of a database is restored. Approaches based on compensation transactions, semantic knowledge or access information are mostly not appropriate for CAD transactions. The reason for this lies in the special character of CAD transactions. A design activity is unpredictable because of its interactive nature and compensating transactions cannot be predefined generally when its actions are not predictable and based on user interactions. Another class of solutions used mostly in design environments realizes concurrency control by providing designers different versions of database objects. Public/private database architectures and checkout/checkin approaches make use of multiversioned data. In the concept of checkout/checkin, a transaction checks out a design object from the public database, modifies it in its private database and writes it back into the public database after the completion of its modifications. [3] describes the general requirements for version management systems, unifies several proposals for version modeling in engineering databases, and provides a common terminology. Purposes for versions in database systems, such as concurrency control and recovery, are summarized in [8], which also presents an 5

6 approach to version support for engineering database systems. A design object is defined as a set of versions including one current version. [27] presents a transaction model based on existing models of engineering transactions and nested transactions. This model refines the notion of checkout environments by coupling it with the notion of nested transactions. The database is separated into a public database and a collection of semi-public databases which are associated with each transaction on the transaction hierarchy. [24] addresses the problem of correct collaboration in asynchronous cooperative information systems. The paper gives a solution of collaboration correctness that is based on the evaluation of the collaboration process. Artifacts are replicated at different sites and changes made at one site are asynchronously propagated to the other sites. The dynamics of cooperative design activities is leading to new approaches to design environments [9]. An approach to managing concurrent activities in collaborative environments is presented in [8]. The need for cooperations increases with the size of projects. New methods of cooperation primitives address the requirement of nonserializable cooperative interactions. Interactive notification policies and group paradigms are defined to enable designers to work closely together and exchange incomplete designs [26]. Group-oriented transaction models are based on a notion of a group. Long transactions are categorized into groups and cooperation within a group is allowed in ways not permitted outside. A group-oriented transaction model is presented in [28]. The traditional transaction model is extended by categorizing transactions into group transactions and user transaction. Group transactions reserve objects from the public database into the corresponding group database and user transactions reserve objects from the group database into the corresponding user database. Every user transaction is realized as a subtransaction of a group transaction. The transaction group model [22] proposed for the object-oriented database ObServer defines active entities called transaction groups that are used to isolate the behavior of one set of cooperating agents from another. Hierarchical organized transaction groups facilitate and control cooperative work by replacing classical locks with a lock mode, communication mode pair. [30] describes a transaction model for design databases, called cooperative transaction hierarchy. In [3], a programmable correctness criterion for cooperative transaction hierarchies structures the interactions among cooperative transactions and allows controlled data sharing. A synchronization algorithm is defined that uses a transaction group s correctness criteria to ensure that the operations accepted by the group are ordered correctly. A discussion about advantages of multi-copy versus single-copy systems is also included. ACTA is a comprehensive framework that facilitates the formal description of properties of extended transaction models [7]. This first-order logic based formalism can be used to specify and reason about the effects of transactions on objects and the interactions between transactions. A taxonomy of correctness criteria in database applications based on ACTA is presented in [5] and cooperative transactions and various other correctness criteria are categorized and compared. A formal description of sagas is presented in [2]. 3 A version model for shared engineering databases A design object in product development is mostly modeled as an aggregation of data that is stored in various evolutionary versions. This section presents a version model for shared engineering databases that is an extension of checkout/checkin concepts and savepoint approaches. There are two main objectives of this version model. First, a recovery method for long design transactions is provided. The version model defines a framework to modify design objects in different stages of development. Versions inside a version branch can be used to undo modifications and go back to previous results. The second objective is to support cooperations between parallel design activities. Versions are regarded as partly consistent objects that can be accessed by concurrent transactions. Although transactions are now allowed to read uncommitted changes of others, a notion of consistency conditions is being provided. Active notification delivery mechanisms are used to support additionally the intra-transaction information exchange among parallel object versions. This section presents a concurrency control component that is based on objects replicated at different sites. These replicas are called savepoints and represent definite states of a design object 6

7 during its development by a certain design transaction. Since several savepoints represent different states of the same object, these savepoints are regarded as object versions. The version model provides primitives to create, delete and modify object versions. The presented multi-version concept is based on ideas of [20] and [8], where some of the terminology has been taken from. The presented transaction model still supports the notion of transactions but the transaction primitives commit and abort are redefined and based on much finer granularity. Instead of making all modifications public, a commit is applicable to single database objects. The action of aborting all modifications in a transaction is replaced with an operation to take back several steps in the development of single design objects which is much more suitable in a design activity. Hydraulic Automobile Brake part-of part-of part-of Cylinder Brake Drum Shoes part-of Cylinder Block part-of Piston Fig. 2: An example of a composite object hierarchy Uncommitted data is often called dirty [25]. A consequence of committing single objects instead of whole transactions is that users are able to read dirty data of other in-progress transactions. This means a violation of consistency in the traditional transaction model. Committing writes before end of transaction violates consistency conditions necessary to be degree consistent according to Grays degrees of consistency [25]. When the overall design process is regarded as a process of continuous design work, its subdivision into separate transactions with consistent states is not possible. The rigid isolation of traditional transactions prevents the support of communication and cooperation between different design activities which makes them less efficient. The goal of making subresults accessible to other designers is to support to merge related work already during the design process itself. The presented approach guarantees that information is exchanged only when this information is classified by its designer as a result that is consistent to a certain extent. Therefore, savepoints are regarded as partly consistent subresults. These subresults can be used to exchange information on a relatively consistent level. The description of the consequences of the presented approach contains vague terms such as relatively consistent or to a certain extent. A formal transaction model gives a formal definition of the semantics of the transaction model [2]. This model uses the ACTA formalism in order to define a correctness criterion for the presented approach. According to the limited size of the paper, the formal model cannot be included in this paper. The multi-version concept is applied to design objects. Design objects are an aggregation of design data that is continually subject of dynamic evolution by distributed design teams working together. Design objects typically are composite objects which means that an object may consist of several components which may be recursively again design objects. These part-of relations build a hierarchy of composite objects forming a directed-acyclic graph (DAG). The hierarchical composition of a complex design object is often called configuration of an object [20]. Figure 2 shows an example of an object configuration. The hydraulic automobile brake consists of a cylinder, a brake drum and shoes, the cylinder itself consists of a cylinder block and a piston. Functional dependencies among the components of a configuration cause that e.g. modifications of a cylinder may effect modifications not only to the automobile brake but also to the brake drum and shoes. A design activity is a sequence of design operations done by a designer or a design group. Design activities typically last a long time and are executed by CAD tools in interaction with designers. These activities have to be mapped to database transactions when the design object is stored in a database system. 7

8 A general problem is the granularity of concurrency control mechanisms. The term granularity refers to the size of the objects that can be subject of concurrency in a DBMS, e.g. areas, files, individual records, field values, etc. Regarding the granularity of lockable units, there is a tradeoff between concurrency and overhead. A fine locking granularity leads to a maximum on concurrency whereas a coarse granularity leads to fewer locks and less maintaining. Using a coarse granularity means to have fewer locks and less maintaining but there will be less concurrency. In the presented transaction model, single composite database objects in the part-of hierarchy are chosen as subject of concurrency control because concurrency and cooperation support is the main emphasis. That means that operations on a design object also affect its components. Although design objects are not always shown as composite objects for clarity reasons (e.g. in figures), these objects are always represented as complex objects. The version model separates the shared database into different logical areas. A shared object pool represents all shared design objects. A private version pool is associated with every design activity and contains private object copies of the shared object pool. The notion of a group version pool (e.g. [20]) is not defined since the approach presented here supports cooperative work even without the definition of inflexible or predefined group structures. Objects in the shared object pool are called global or shared object, copies of a shared object are called savepoints or transient objects. A comparison between these object types is shown in table. A long running design activity on a global object is initialized by a checkout operation. This operation copies a global object from the shared database into a private version pool. Next, all write operations are executed on the transient object. Several users are able to checkout the same global object and modify these transient objects in parallel in their own version pool. In this optimistic approach, writing back the modifications of a transient object into the global object needs to consider the updates of the global object since checking out. The global object may have to be reread and all modifications have to be integrated in the transient object before it can be checked in. Shared Object global stored in the shared object pool consistent defined primitives: checkout Savepoint Transient Stored in a private version pool Partly consistent Defined primitives: create_savepoint, retract_savepoint, checkin Table : A comparison between shared objects and savepoints Designers are able to create new savepoints and to restore old savepoints if errors in their current design occur. A version pool consists of all versions of an object created by a transaction. These versions are ordered in a linear list which is called a version branch. A version pool consists of a collection of branches that represent versions of different objects. When a transaction has checked out n different objects, there are exactly n version branches in its version pool. A version is called a current version of a design object if it is the most recently created version in its version branch. A current version is the in-progress copy because all modifications are executed on this object. Versions that are not current versions are also called frozen versions. The latest frozen savepoint represents the latest copy of the current version before the current updates have started. 8

9 Shared Object Pool Version Pool t ob ob t ob t 2 ob t 3 Version Pool t 2 ob2 ob t 2 ob t 2 2 ob t 3 2 ob t 2 2 ob t Fig. 3: An example of a version pool scenario Figure 3 shows an example for the presented specifications. Objects ob and ob2 are members of the shared object pool. Two design transactions t and t 2 have checked out object ob, transaction t 2 has checked out object ob2 additionally. A transient object is specified by an index indicating the transaction that has checked it out. Additionally, a suffix denotes the number of this savepoint. Object ob t 2 represents the second savepoint of transaction t of the global object ob. Objects ob t 3, ob t 2 3, and ob 2 t 2 are current versions and 2 ob t, ob t 2 2 2, and ob 2 t 2 are latest frozen versions. The main purpose of introducing savepoints is recovery. Savepoints allow returning to previous versions if design changes do not yield to a better design. The main purpose of classifying savepoints into version pools is the representation of alternatives. While a version pool represents a linear evolution of a design object, the set of all version pools represent all alternative developments. These alternatives correspond to different transactions but not necessarily to different designers since one designer is able to start several transactions in order to examine different alternatives. Another purpose is performance because local databases can be chosen as a version pool of a transaction in a distributed database system. Table 2 shows the primitives of the version model. Four operations are defined to enable users to operate on version pools. Operation checkout is used to copy a global object into a private version pool. The new object is set as the current version of this version branch. Operation checkin makes modifications in savepoints public by copying a savepoint to the global object. Savepoints of this Primitive checkout checkin create_savepoint retract_savepoint Semantics Create a new version branch in the private version pool and copy a global object into the new version branch Copy a transient object back into the shared database, delete ist version branch Create a new savepoint Delete a savepoint and go back to the previous one Table 2: Primitives of the version model 9

10 version branch and the version branch itself are deleted because they are not used any more. Operation create_savepoint creates a new savepoint of an object. Similar to operation checkout, it creates a new copy of an object but it creates no new version branch. Rather, the new transient object is appended at the end of the version branch and becomes the current version in this version branch. Operation retract_savepoint is used to go back to the previous savepoint. After this operation, the old current version is deleted and the latest frozen savepoint becomes the new one. The checkout approach uses optimistic locking because it allows multiple checkouts of a shared object. The problem, however, is the checkin. It is the task of the designers to merge results into one consistent object. Different results have to be integrated and when current versions are incompatible, design work has to be redone. In order to give a solution to this problem, the strict isolation of parallel object versions is weakened. In contrast to traditional checkout mechanisms, version pools are physically not private but semi-public. That means that version pools are also stored in the shared database and designers are able to read transient objects of colleagues when it is allowed by the transaction system. Whereas current savepoints, which represent objects of in-progress work, are locked exclusively to prevent consistency violations, the exclusive lock is being retracted when a new savepoint is created. That means that frozen savepoints are made public for read accesses to other transactions. A result of this behavior is that transactions are not serializable any more because they are able to read modifications of transactions. The transaction model drops serializability in favor of intra-transaction information exchange. The concept of savepoints restricts these intra-transaction database accesses to a limited set of object versions that are classified by a transaction as partly consistent. Another consequence of storing savepoints in the shared database instead of in private database is that cooperative database accesses of group transactions (which are described in the next section) can be applied even for transient objects. Using the version models as a basis, means of coordination and cooperation provide information flow among related transactions. The objective is to enable transactions to get an overview on the relationships of all design activities and to integrate related design result in their own work. Even if the work of a single user is slowed down by integrating results of colleagues, the overall design is performed more efficiently. Communication and information exchange during the earlier phases of a design activity make it easier to merge results later. The version model enables users to read parallel versions and inform themselves about parallel design work. The drawback is that users have to do this on their own initiative and in regular intervals. In order to provide an active information delivery, active facilities inform transactions about events of parallel version branches. In detail, when a new savepoint is being created, all transactions that work on transient versions of this object are being informed and get the right to read the partly released object. Similar notifications are sent when checkin or retract_savepoint operations are executed. In figure 3 for example, the creation of t savepoint t ob is notified to transaction t 2 and the creation of ob 2 is notified to t, respectively. Designers have to regard the overall design process in order to ensure that their work is compatible with the work of colleagues. Dependencies between design objects even require considering developments of other design components. These dependencies may be geometrical as well as functional relationships. Regarding the example configuration of figure 2, modifications of a cylinder may cause modifications of the brake shoes or drums. For this reason, the version model allows designers to determine the set of objects that influence his work. This set is called set of relevant objects. Automatic notifications to a designer are sent not only when a parallel object version is modified but also when an object of his set of relevant objects is being changed by a parallel transaction. The primitives of the version model are completed by operations to determine the set of relevant objects of a design transaction. 0

11 Primitive insert_to_relobj remove_from_relobj Semantics Insert an object to the set of relevant objects Remove an object from the set of relevant objects Table 3: Additional primitives of the version model It has to be mentioned here, that some primitives of table 2 appear similar to the concept of nested transactions or mechanisms such as sagas, described shortly in section 2, but in detail there are great differences from these approaches. First of all, the subject of the transaction primitives are single database objects and not whole transactions. Transient objects are not released totally but are still controlled by their owners. Recovery of long transaction is not the only objective of the transaction model. Communication and cooperation support is provided on the basis of savepoints. Beneath supporting asynchronous cooperation by the version model, the transaction group model presented in the next section even supports synchronous cooperations and parallel write operations on shared design objects. 4 Transaction group model While the version model supports asynchronous design work on different object copies (multicopy approach), the transaction group model supports synchronous cooperative work (single-copy approach). Similar to [30], the proposed transaction group model is defined by an external and an internal protocol. Both protocols are based on the notion of a transaction group. A transaction group is a group of cooperating transactions that allows designers to work closely together on shared data. The external protocol describes the synchronization among transactions and/or transaction groups. Since the external protocol does not ensure correctness inside a transaction group, internal protocols are introduced here to prevent uncontrolled sharing that may lead to consistency violations. As described before, intra-transaction interactions and the activity of sharing data lead to nonserializable transactions. The external protocol isolates transactions as long as they are not member in the same transaction group. In contrast to approaches such as [3], that define rigid hierarchies of transaction groups structured for a special design task, the modification of the set of transaction groups is allowed even during runtime. That means that two transactions may be serialized before they decide to cooperate. When their cooperation is finished, they are serialized again by the external protocol. In this way, this model provides much more flexible structures and allows more dynamically design processes than related approaches. 4. The external protocol Similar to comparable approaches (e.g. [26], [27], or [22]), group transactions are based on the notion of a group. Inside a transaction group, transactions are able to share data and exchange information. While the term transaction group denotes the set of cooperating transactions, a group transaction denotes a transaction controlled by this group. Since cooperation is limited to transactions inside groups, cooperation is not allowed outside. Database accesses in a transaction group are treated as accesses of a single transaction. Figure 4 shows the architecture of a group transaction system based on cooperative transactions. The database objects that are locked by the transaction system are sketched with a grey background. Additional to primitives to start or commit transactions, two new primitives are introduced to enable users to insert or remove transactions into transaction groups (table 4). When a transaction has locked an object, it is the only member in the transaction group. Hence, this transaction is the only one that is able to invite other transaction to cooperate towards the design of this object.

12 Activity Activity 2 Activity 3 Design Activities Transaction Group Model Transaction Group Transaction External protocol Shared Database Fig. 4: Access to shared data by group transactions In the presented approach, transaction groups have the following properties: Every database object is assigned to exactly one transaction or transaction group, respectively. Hence, not more than one transaction/transaction group is able to access a database object exclusively. Since savepoints are represented as regular database objects in the shared database, the transaction group model is also applied to savepoints effecting that cooperative data accesses are also provided to transient objects. Designers are able to enlarge an asynchronous collaboration easily to temporary synchronous cooperation in order to solve special problems together. When a transaction locks an object exclusively, this transaction is automatically the first member in its transaction group. An empty transaction group is equal to the state of no locking. Only transactions that have the write permission (i.e. they are member of the transaction group) are able to execute the primitives of table 4. The extended locking management is an example of the more sophisticated database mechanisms of this approach. Similar to other database capabilities, the database system itself uses database models about transactions and transaction groups to provide a more flexible and intelligent behavior that is conform to the current situation. 4.2 The internal protocol The external protocol specifies transaction groups guaranteeing that synchronous cooperations are limited to members of a transaction group. The protocol does not specify any correctness criteria inside a transaction group. Cooperation support between two arbitrary transactions can lead to lost updates and other inconsistencies when their operations interfere with each other. When there is no guarantee of consistency, the transactions are responsible for the consistency of the data. The lack of a protocol for internal synchronization is compensated by the internal protocol. New sharing policies are introduced to enforce a higher degree of conflict-free data accesses in group transactions. A higher Primitive insert_to_tc remove_from_tc Semantics Insert a transaction into a transaction group Remove a transaction from a transaction group Table 4: Primitives of the external protocol 2

13 Activity Activity 2 Activity 3 Design Activities Transaction Group Model Transaction Group Transaction External Protocol Floor Control Internal Protocol Shared Database Fig. 5: Integration of the external and the internal protocol degree of concurrency is accompanied by a lower degree of consistency. These policies are informal notions of correctness that are not based on serializability. In conferencing environments and collaborative applications, the concept of floor control has been developed to coordinate concurrent usage of shared resources. Although this technique is used currently just in collaboration environments, floor control can be regarded as a general technique to deal with conflicts in shared workspaces. Floors are temporary permissions that are granted dynamically to coordinate multiple users in shared applications [9]. In the cooperative transaction model, the concept of floor control is used as an internal protocol and integrated into the concept of group transactions. Floor control synchronizes parallel database accesses inside group transactions by imposing different dynamic lock modalities. The internal protocol provides new consistency conditions for design objects. Beside the facility of following synchronous actions of other transactions, floor control provides several advantages for cooperative design activities: The synchronization is under control of the involved transactions. This is an important point because it is up to the design activities to decide in negotiations about the type of synchronizations and access permissions. An intergroup awareness is promoted by transferring the right to grant permissions to the applications. Floors are flexible manipulation permissions. In contrast to the traditional transaction model with its static permissions based on extensive locking mechanisms, floors can be passed simply and dynamically within a group. Floors are short-term manipulation permissions. When a transaction intends to make a contribution, it is able to interrupt other transactions. While atomicity, consistency, isolation and durability properties provide a formal notion of correctness that is based on serializability, floor control mechanisms cannot guarantee the consistency of data in the same way. Interaction among transactions is accompanied by a lower degree of consistency. However, comparing with unlimited cooperations in group transactions, a much higher degree of consistency can be obtained. Since write accesses to data are limited to single transaction while other transactions are able to notice these modifications, problems like the lost update problem or the uncommitted dependency problem do not arise any more in practice. A prerequisite of the 3

14 Primitive init_floor delete_floor ask_token release_token take_token Semantics Initialize a new floor Delete a floor Ask for the token Release the token Take the token Table 5: Primitives of the internal protocol internal protocol is the external protocol which guarantees that the corresponding transactions are aware of the cooperation and have explicitly agreed to the collaboration. The internal protocol only regulates accesses to data that have been locked before by the external protocol. Data accesses to unlocked data or cooperation with transactions outside of transaction groups are still prevented by the external transaction protocol. Figure 5 shows how several design activities can share one group transaction that is synchronized by floor control mechanisms. Numerous floor control mechanisms and policies can be found in the literature that determine how tokens can be requested and specify if users have to release the token explicitly to allow other users to be the floor holder. Among these mechanisms and policies, the presented transaction model provides just some of them that appear to be most advantageous in the situation of cooperative product design. However, other floor control mechanisms and policies could be adapted easily. The mechanism of token passing is used here for the synchronization of transactions. Token passing offers write accesses to shared data in a predefined sequence. Only the activity that holds the token has the right to manipulate the data. Primitives of the internal protocol that provide designers the facilities of token passing are presented in table 5. The internal protocol provides primitives to define intra-group assignment sequences. These primitives allow users to request accesses to shared objects. A precondition to the use of these primitives is a transaction group that has to be created before by primitives of the external protocol. The floor control primitives of table 5 have to be called with the corresponding transaction group as a parameter. 5 Realization aspects This section sketches some aspects of a realization of the presented transaction models. The description concentrates on the transaction system and does not include aspects such as the distribution of data. In the presented realization, design objects are represented in the database in an object-oriented modelling style that includes part-of hierarchies. The reason for using object-oriented database technology is that object-oriented data structures are more appropriate than relational structures to represent complex objects. In the presented realization, a database object concretely consists of a triplet: the object data itself, a set of associated rules, and a transaction group. The set of associated rules specify the active behavior of an object (e.g. automatic notifications) described in section 4. The transaction group specifies the transactions and transaction groups that are working cooperatively on this object (described in section 5). Additional to the object data itself, information about the semantics of an object is stored. This documentary information includes data about the design process, the designer, and the relationships to other objects. A realization of the version model requires efficient data structures for storing copies of complex objects that differ from each other just in some details. There are two main approaches to store copies. The first alternative is to store a copy as a whole copy of the design object, the second alternative is to store only the operations distinguishing a copy from the original. The presented approach uses an extension of the first alternative that uses efficient storage structures to minimize storage 4

15 redundancies. Savepoints are composite objects and sharing is allowed at any level of the configuration. That means e.g. that a checkout is even applied to all of the components of an object. When there are no manipulations to a component, only a reference to the original is stored. When a component is changed, the reference is replaced by a real copy and the modification is executed on this copy. Figure 6 shows a graphical presentation of the data structure of the cylinder example. () and (2) show the data structure before and after modifications of the block of the cylinder have been performed, respectively. Dotted lines indicate that only a reference is stored at this place. This figure shows that even after modifications of some components, links can still be used to represent components (e.g. the piston or the drum) that are not effected explicitly by the modifications. Since components may be again composite objects that are stored in the same manner, this approach leads to very efficient storage structures without much overhead. Original object () Copy Original object (2) Copy Brake Cylinder Block Piston Brake Cylinder Block Piston Brake Cylinder Block Piston Brake Cylinder Block Piston Drum Drum Drum Drum Shoe Shoe Shoe Shoe Fig. 6: Storage structure before () and after (2) performing modifications of the cylinder block The distinction of a database into a shared object pool and several version pools is realized in the shared database by long locks. That means that physically there are no private areas and all data is stored in a shared database. Long locks are used to synchronize long CAD transactions. Read and write operations as well as the presented primitives are serialized according to traditional transaction models based on a strict two-phase commit protocol. It is important to note here, that even primitives such as the create_savepoint operation may consist of several write accesses when a composite object is copied and locked. Current versions are locked by long locks in exclusive mode (X-lock) and all other transient objects are locked in shared mode (S-lock). This allows other transactions to read the frozen Shared Object Pool Version Pool t S S X U ob t ob t 2 ob t 3 ob Version Pool t 2 S S X ob t 2 ob t 2 2 ob t 3 2 Fig 7: Locks of a shared object and its transient objects 5

16 savepoints of other transactions. A global object is locked in update mode (U-lock). Lock U increases the degree of concurrency by granting read accesses on objects that will be updated later [3]. In the presented transaction model, lock U is used in a new special meaning. U-mode is introduced for the primitives of the version model in table 2 (checkout, checkin, etc.) and specifies that these primitives are compatible with each other, even if their executions include write accesses. However, these primitives are not compatible with regular write operations. This specification allows multiple checkout and checkin operations on the same object but does not grant regular write operations on objects that are still checked out. The update lock is set by the transaction system only when a checkout primitive is executed and is removed only by a checkin primitive. The specification of the U-mode and the reduction of the lock mode of modified objects to S-mode before end of transaction done by the checkin primitive are responsible for the nonserializability of these transactions. The extended compatibility matrix for granular locking including U-mode is presented in figure 8. Table 6 sketches the realization of the transaction primitives of the version model. The index t i indicates the transaction that executes the primitive operation. Primitive create_savepoint reduces the lock of an existing current savepoint from X-mode to S-mode when a new savepoint is created. This operation violates consistency conditions in traditional transaction models because subresults inside of uncommited transactions are made public for read accesses and effects the nonserializability of the version model. Primitive Realization checkout t ( ob ) create( ob t ) checkin t t ( n create_savepoint retract_savepoint insert_to_relobj create_version_branch( t, ob t ) lock( ob t ):= X ob ) update( ob ) for all i n t t ( i lock( ob ):= U attach ECA rule for notification : delete( ob t i ) delete_version_branch( ob t i ) release_lock( ob,u) remove ECA rule ob ) t create( ob i + ) update_version_branch( t ) t ( t i t lock( ob i + ):= X lock( ob i t ):= S ob ) t delete( ob i ) update_version_branch( t ) t lock( ob i ):= X attach ECA rule for notification remove_from_relobj remove ECA rule Table 6: Realization of the primitives of the version model 6

17 Event: Condition: Action: create_savepoint call There are parallel version branches considering the composite part-of hierarchy Send automatic notifications:. Find out all transactions that work on parallel versions 2. Select a means of communication 3. Find out communication addresses 4. Send notification Table 7: ECA rule for an asynchronous progress notification The mechanism of asynchronous progress notification of the version model is realized by concepts of active database systems. Active databases integrate inference mechanisms with database systems by using ECA (event-condition-action) rules to define an active behavior [7]. Internal events such as database operations trigger rules. The condition of a rule is validated when its event is triggered. The action of a rule is executed when the rule is triggered and the condition of the rule is satisfied. The primitives of the cooperative transaction model are defined as database events. The example of table 7 sketches an ECA rule that informs parallel transactions when a new savepoint is inserted into a private version pool. Whenever a create_savepoint operation is being executed on an object, the events of all attached rules are triggered and their conditions are validated. Rules that react to checkout, checkin, and retract_savepoint operations, or even to some conflict situations, are defined analogously in the database. Different collaboration services, from up to video conferencing, can be used for information exchange. Again, the behavior of the system depends on the contents of database models. The action of an ECA rule requires information about the relations between database transactions and the designers executing them. Further, a user model which includes information about the organization and the communication infrastructure of a company and its employees is needed to find out the available means of communication the addresses of the designers. The kind of communication really used depends on the communication infrastructure model and modeled preferences of users. The hierarchical locking mechanism also defines conflicts between objects in different configuration levels and therefore the notification mechanism even works when components of objects are subject of modifications. This means that designers working on a higher level component are also notified when a lower level component of this design object is been updated. Coupling modes define the time actions are executed relative to the transaction where the event occurs [29]. For immediate coupling, the action is executed immediately when the event occurs, for deferred coupling, the action is executed when the transaction commits. Since CAD transactions are long, it makes no sense to wait for the commitment of a transaction. Hence, an immediate coupling mode is chosen. This means that notifications about updates are sent immediately when the triggering event (e.g. primitive create_savepoint) occurs. When consistency checks are realized by ECA rules, the create_savepoint primitive can be used as the event for starting the check. As partly consistent states, savepoints compose transactions into subtransactions that are predestined for intra-transaction consistency checks. The realization of the transaction group model is based on an approach to granular locking [25]. Gray extends the compatibility matrix that describes which accesses are granted by the following access modes: X (exclusive access), S (shared access), IS (intention share mode), IS (intention share mode), IX (intention exclusive mode), and SIX (share and intention exclusive mode). Before 7

18 mode requested by t i IS IS IX S SIX X yes yes yes yes U no IX yes yes no current mode of object ob S SIX yes yes yes no no X no U no no no no no yes C ( t, ob) = i yes if t T [ ob] no i C otherwise Fig. 8: An extended compatibility matrix for granular locking transactions are able to access a database object, they have to acquire a lock. Shared mode S grants read access, X grants read and modify access, IS read access to some parts of a composite object, IX read and write access to some parts of a composite object, and SIX indicates that locking is being done at a lower node of a subtree in the part-of hierarchy. In order to realize the specification of the cooperative transaction model, Grays compatibility matrix for granular locking has been modified by two extensions. First, U-mode is introduced in the compatibility matrix to realize the checkout/checkin primitives of the version model. As described before, U-mode is only compatible with itself and allows multiple checkout/checkin operations in parallel. The realization of group transactions requires the introduction of transaction groups in the compatibility matrix. A group of cooperating transaction is denoted by T C. Since single database objects were chosen as the granularity of concurrency control mechanisms (see section 4.), a transaction group assigns a set T C to every database object. T C [ ob ] indicates the set of transactions ti TC [ ob] that have the right to access object ob. Comparing to Gray s original compatibility matrix, every no is replaced by a condition C, that tests if the requesting transaction t i is member of the corresponding transaction group T C [ ob]. A lock is not been granted only if the locks are incompatible according to Grays locking matrix and if condition C is false. Since every component in the part-of hierarchy is assigned its own transaction group, acquiring a lock requires requesting all of its ancestors in the composite hierarchy in intention mode first. The additional primitives of the external protocol of table 4 insert or remove transactions into or from a transaction group, respectively. Meta data used for floor control (e.g. information about the chosen policy, the current token holder, etc.) is stored in the data structure of a transaction group. Primitives of the internal protocol (table 5) modify this meta data (e.g. by changing the current token holder) and therefore transactions have to have write permission (X-mode) to execute them. The external protocol restricts these operations to members of the corresponding transaction group. Write operations inside a transaction group are examined by a floor control management that checks every operation if it can be granted according to the selected policy. 8

19 6 Conclusion The presented cooperative transaction model for cooperative product design violates traditional consistency requirements. However, the presented transaction model does not address to the almost impossible goal to maintaining the absolute consistency of mostly incomplete product data. Rather, it provides new methods to develop product data more efficiently and to support designers to integrate their work to a common solution in Simultaneous or Concurrent Engineering processes. The approach tries to come over the two different approaches of cooperation and coordination by integrating coordination approaches into cooperations and vice versa. The presented result is a combination of both approaches that allows information exchange and cooperative accesses on the basis of a multiversion concept and group transactions. Object versions are used to realize an intra-transaction communication and cooperation. Since these interactions lead to nonserializable transactions, the traditional transaction model is replaced by a nonserializable model that uses savepoints as a recovery mechanism. It has to be mentioned here, that the presented approach extends the traditional transaction model, but does not replace it. When the additional primitives of the cooperative transaction model are not used, the external protocol applies the conventional two phase commit. The more elaborated mechanisms presented here are limited to CAD transactions and traditional database applications are handled in the traditional way. In order to allow a maximum of flexibility in CAD environments, the schemata of design objects can also be declared as subject of development. One further requirement to CAD databases may therefore be to support not only versions of design objects but also versions of object schemata. Although this paper presented a version model for design objects, the overall approach can be adapted to object schemata without limitations. The only prerequisite is that these meta schemata are not represented as internal structures but are represented explicitly as database objects. The presented approach is realized in a prototype called Active Semantic Network (ASN) on the basis of an object-oriented database system. The development and realization of this knowledge base is granted in part by the Collaborative Research Center SFB (Sonderforschungsbereich) 374 Development and Testing of Innovative Products - Rapid Prototyping at the University of Stuttgart, Germany, through the German DFG. In this research center, several institutes of the University of Stuttgart and the Fraunhofer-Society are working together with Daimler Chrysler AG Research to find new ways and mechanisms to make product development more efficient. References [] P.A. Bernstein and E. Newcomer, Principles of transaction processing (Morgan Kaufmann, San Francisco, California, 997) [2] O. Eck, Ein kooperatives Transaktionskonzept für CAD-Datenbanken (Shaker Verlag, Aachen, Germany, 2000) [3] J. Gray and A. Reuter, Transaction Processing: concepts and techniques (Morgan Kaufmann, San Mateo, California, 993) [4] J.E.B. Moss, Nested Transactions: An Approach to Reliable Distributed Computing (The MIT Press, Cambridge, Massachusetts 987) [5] N. S. Barghouti and G. E. Kaiser, Concurrency Control in Advanced Database Applications, in: ACM Computing Surveys, Vol. 23, No. 3 (99) [6] A. Brayner, T. Härder and N. Ritter, Semantic serializability: A correctness criterion for processing transactions in advanced database applications, in: Data & Knowledge Engineering, Vol. 3 (999) -24 [7] P.K. Chrysanthis and K. Ramamritham, Synthesis of Extended Transaction Models Using ACTA, in: ACM Transactions on Database Systems, Vol. 9, No. 3 (994) [8] K.S. Dittrich and R.A. Lorie, Version Support for Engineering Database Systems, in: IEEE transactions on software engineering, Vol. 4, No. 4 (988) [9] H.P. Dommel and J.J. Garcia-Luna-Aceves, Floor control for multimedia conferencing and collaboration, in: Multimedia Systems, Vol. 5 (Springer-Verlag, 997) [0] K. Eswaran, J. Gray, R. Lorie and I. Traiger, The notion of consistency and predicate locks in a database system, in: Communication of the ACM Vol. 9, No., (976) [] A.A. Farrag and M.T. Öszu, Using Semantic Knowledge of Transactions to Increase Concurrency, in: ACM Transactions on Database Systems, Vol. 4, No. 4 (989) [2] H. Garcia-Molina, Using Semantic Knowledge for Transaction Processing in a Distributed Database, in: ACM Transactions on Database Systems, Vol. 8, No. 2 (983) [3] R.H. Katz, Toward a Unified Framework for Version Modeling in Engineering Databases, in: ACM Computing Surveys, Vol. 22, No. 4 (990)

20 [4] M. Klein, Supporting Conflict Resolution in Cooperative Design Systems, IEEE Transaction on Systems, Man and Cybernetics, Vol. 2, No. 6 (99) [5] K. Ramamritham and P.K. Chrysanthis, A taxonomy of correctness criteria in database applications, in: The VLDB Journal, No. 5 (996) [6] K. Salem, Altruistic Locking, in: ACM Transactions on Database Systems, Vol. 9, No. (994) 7-65 [7] M. Stonebraker, The integration of rule systems and database systems, in: IEEE Transactions on Knowledge and Data Engineering, Vol. 4, No. 5 (992) [8] D. Agrawal, J.L. Bruno, A. El Abbadi and V. Krishnaswamy, Managing Concurrent Activities in Collaborative Environments, in: Prc. Of the Third Int. Conf. On Cooperative Information Systems (995), 2-24 [9] J, Bardram, Designing for the Dynamics of Cooperative Work Activities, in: CSCW 98, Seattle (998) [20] H.T. Chou and W. Kim, A Unifying Framework for Version Control in a CAD Environment, in: Proceedings of the Twelfth International Conference on Very Large Data Bases (Kyoto, 986) [2] P.K. Chrysanthis and K. Ramamritham, ACTA: The Saga continues, S.K. Elmagarmid, ed., Database Transaction Models for Advanced Applications (Morgan Kaufmann Publishers, California, 992) [22] M.F. Fernandez and S.B. Zdonik, Transaction Groups: A Model for Controlling Cooperative Transactions, in: Third International Workshop on Persistent Object System: Their Design, Implementation and Use (Queensland, Australia, 989) [23] H. Garcia-Molina and K. Salem, Sagas, in: Proceedings of the ACM SIGMOD International Conference on Management on Data (987) [24] J.R. Getta, L.A. Maciaszek and I.T. Hawryszkiewycz, Correctness of Asynchronous Distributed Cooperation, in: CoopIS-95 Proceedings (995) [25] J.N. Gray, R.A. Lorie, G.R. Putzolu and I.L. Traiger, Granularity of Locks and Degrees of Consistency in a Shared Data Base, in: G.M. Nijssen, ed., Modelling in Data Base Management System (North Holland Publishing Company, 976) [26] G.E. Kaiser, Cooperative Transactions for Multiuser Environments, in: W. Kim, ed., Modern Database Systems (ACM Press, 995) [27] W. Kim, R. Lorie, D. McNabb and W. Plouffe, A Transaction Mechanism for Engineering Design Databases, in: Proceedings of the Tenth International Conference on Very Large Data Basis (Singapore, 984) [28] P. Klahold, G. Schlageter, R. Unland and W. Wilkes, A transaction model supporting complex applications in integrated information systems, in: ACM-SIGMOD International Conference on Management of Data (Austin, 995) [29] D.R. McCarthy and U. Dayal, The Architecture Of An Active Data Base Management System, in: ACM SIGMOD International Conference on Management of Data (989) [30] M.H. Nodine and S.B. Zdonik, Cooperative Transaction Hierarchies: A Transaction Model to Support Design Applications, in: Proceedings of the 6th VLDB Conference (Brisbane, Australia, 990) [3] M.H. Nodine, S. Ramaswamy and S.B. Zdonik, A Cooperative Transaction Model for Design Databases, in: S.K. Elmagarmid, ed., Database Transaction Models for Advanced Applications (Morgan Kaufmann Publishers, California, 992) Dieter Roller is a member of the board of directors of the Institute of Computer Science, University of Stuttgart and also holds the position of the lecturing dean of the computer science faculty. Further he is the head of the Graphical Engineering Systems Department and full professor of computer science. Additionally he has beed awarded the distinction as a honorary professor of the University of Kaiserslautern. Oliver Eck is a research assistant at the Institute of Computer Science, University of Stuttgart. The emphasis of his research activities include product database systems and knowledge based systems for CAD. Stavros Dalakakis is a research assistant at the Institute of Computer Science, University of Stuttgart. His currently research activities are focused on the fields of knowledge represention and modeling. 20