Apparent Versioning and Concurrency Control in Object-Oriented Databases Wojciech Cellary
The Franco-Polish School of New Information and Communication Technologies Poznan, Poland
[email protected]
Abstract
Genevieve Jomier
Universite Paris-Dauphine LAMSADE Paris, France
[email protected]
The problem of consistency of object-oriented databases is considered, when objects contained in the database are multiversion, and they are accessed by concurrent transactions. In such databases there are two aspects of the consistency problem, one related to concurrency, as in monoversion databases, and the other related to versioning. In this paper the problems of mutual dependencies of version management upon concurrency control are studied. It is shown that in di erent approaches developed up to date in di erent application areas, these aspects of consistency are not separated. As a result, a tradeo is assumed between versioning functionalities provided and concurrency degree allowed. In [6] an approach to object version management has been proposed, called the database version approach. It is shown that in this approach, object version management is orthogonal to concurrency control. As a result, there is no more need for the tradeo : versioning functionalities provided are rich, and concurrency degree is high. In the paper organization of version management and concurrency control for a multiversion object-oriented database is described in detail.
1 Introduction Data versioning has been used since an early date to improve database reliability and performance. To improve reliability, data versioning is used as the main tool of recovery and rollback [12]. Rollback techniques based on versioning are used to guarantee transaction atomicity|one of the fundamental transaction properties| and thus contribute to the solution of the database consistency problem. To improve performance of concurrency control|a basic tool of database consistency maintenance| multiversion concurrency control models have been proposed, and a number of multiversion concurrency control algorithms. A comprehensive study of them is presented in [5]. The common feature of this kind of versioning is its transparency from the user point of view. A database user ignores the existence of such data versions; he views the data as single items. In new database applications, especially objectoriented ones, like CAD or CASE, a user needs to view and to manipulate di erent versions of the same object. They have to be apparent for the users. For example, in a CASE application, an object, which contains the source of a program, may exist in many versions corresponding to successive releases of this program. It may also exist in many versions because of di erent program variants corresponding to di erent operating systems. Apparent object versions renew the problem of database consistency and call into question the tools for its maintenance developed in monoversion databases. In monoversion databases the problem of consistency is stated as follows. A monoversion object is de ned as a pair: (object identi er, object value). A monoversion database is de ned as a set of objects, and a monoversion database state as the set of values of all the objects contained in the database. A monoversion database is considered to be consistent if it is in a state that accurately represents a state of the real world modeled. For example, let a database be devoted to the storage of information on
components of a car, such as wheels, tires, locks, keys, etc. Let this database contain, among others, two objects corresponding to the lock and the key used in the car. This database is consistent if the information contained in it corresponds to a real life situation. If the lock is changed in the car, and the database is not updated, nevertheless it remains consistent, because it still represents a real world state from before the change. However, it becomes inconsistent if, after the change, only the lock is updated in the database, while the key remains old. To maintain database consistency, transactions are used, which transform one consistent state of the database into another [11]. We emphasize that a transaction transforms the entire database state, even if it has access to only some objects. If transactions operating on a database are correct, which is assumed in all database management systems, a potential source of violation of database consistency is concurrent execution of a set of transactions. To preserve database consistency, transactions are serialized, mostly by the use of locking algorithms [5]. In summary, assuming a reliable system and correct transactions, concurrency control ensures the consistency of monoversion databases. In multiversion databases the consistency problem is more complex. Now, an object, which is multiversion, is a pair: (object identi er, set of object versions). An object version is a pair: (version identi er, version value). A multiversion database is de ned as a set of multiversion objects. A multiversion database state is de ned as the set of the values of all the object versions contained in the database. However, a multiversion database state de ned in this way does not re ect any state of the real world, so it is not consistent in the above sense. In fact, it is a collection of elements corresponding to di erent real world states. For example, if two versions of object Left Back Wheel are stored in the database, one of thickness 12 cm and the other of thickness 15 cm, the database state does not re ect any real life situation,
because a wheel may be either of 12 or 15 cm thick. Each Left Back Wheel version corresponds to one of two real world variants. To illustrate the diculties related to updating in this case, consider a multiversion database containing two objects: Left Back Wheel that exists in two versions: (12 cm thick, shiny) and (12 cm thick, matte); and Left Back Tire that exists in one version (12 cm thick). The tire ts together with both variants of the wheel. If a user updated the wheel version (12 cm thick, shiny) for (15 cm thick, shiny), this variant of the wheel would not t together with the tire. If he updated both wheel and tire for 15 cm thick, then the tire would not t together with the other variant of the wheel. If he simply added new versions of the wheel and tire of 15 cm thick to the database, the matte wheel of 12 cm thick would not t together with the tire of 15 cm thick, and the shiny wheel of 15 cm thick would not t together with the tire of 12 cm thick. It is clear that some links between object versions must be established and maintained to identify those that correspond to successive real world states as they appear during time evolution, or state variants. They compose a part of the database, a context, that must be maintained consistent. Such a part has been noticed in [18] and called a consistency surface. An object version may be updated only in the context of the versions of other objects that compose a consistent part of the database. This means that most often an object version cannot be updated separately, but only together with the object versions composing a consistent database part. To this end, update operations must be embedded in transactions. A transaction must contain all the update operations necessary to take a database part from a consistent state to another consistent state. However, if an object version appears simultaneously in di erent contexts, a transaction is required to take each of the database parts concerned from one consistent state to another consistent state. This requirement causes most of the trouble, because an object version may be linked with versions of di erent objects in di erent contexts. These versions may themselves appear in still di erent contexts
and may be linked with still di erent objects, etc. The problem is complex and hard enough when only one transaction at a time is admitted. It becomes really very hard when we consider multi-user systems and concurrency between transactions, commonly required in database applications. In summary, assuming reliable systems, in multiversion databases there are two aspects of the consistency problem, one related with concurrency, as in monoversion databases, and the other related with versioning. Up to date, these two aspects have not been treated as the orthogonal ones. It followed mostly from the fact that the concept of a context was not a part of the data model. As the result, either versioning functionalities were poor, or concurrency degree reduced. In this paper we show that these two aspects may be orthogonal providing an appropriate data model of a multiversion database. Then both versioning functionalities are rich and concurrency degree high. The paper describes a solution of the concurrency control problem in the database version approach presented in [6]. Organization of this paper is the following. In Section 2, three main approaches to versioning are pointed out. In Section 3 the basic concepts of the database version approach are presented. Section 4 is devoted to the organization of version management and control data structures used in the database version approach. Section 5 deals with the concurrency control problems. Potential con icts between transactions are discussed and locking schemas of transactions are shown. Section 6 concludes the paper.
2 Versioning versus Concurrency In this section we point out three main approaches to management of multiversion databases. They di er from one another by the tradeo assumed between versioning
functionalities provided and the degree of concurrency allowed. In the rst approach, database management system recognizes versions of an object, but does not recognize contexts. Entire responsibility for context identi cation is moved to the users. A drawback of this approach is that a database becomes quickly overcome with a number of obsolete object versions which cannot be updated or deleted [15]. The second approach consists in total ordering of versions composing a multiversion object, and partial ordering of versions of all the objects [1, 2]. The main drawback of this approach is the lack of variants that are essential for all the design applications. The third approach consists in explicitly distinguishing di erent contexts [3, 4, 8, 10, 13, 14, 16]. In this approach, composition is used to represent consistency. As a result, any time a new version is appended (checked-in) to the archive, all the con gurations on the path from this version to the con guration hierarchy root have to be spawned to incorporate the new version. Usually, the new con gurations must be laboriously constructed by hand. The main drawback of all the approaches mentioned above is that contexts are not maintained enough automatically. Somehow or other, supported more or less, a user, instead of the database management system, is responsible to maintain the contexts. This reduces considerably functionality of the multiversion databases, because context maintenance is a laborious job. Another important consequence of this drawback are diculties with concurrent execution of transactions. A user, being responsible for maintenance of contexts, is unable to take into account another user operating in parallel on the same database. As a result, either updating is eliminated followed by overcoming the database by obsolete object versions and contexts, or concurrency degree is extremely reduced.
3 Database Version Approach An approach to management of multiversion databases di erent from all the approaches mentioned above has been proposed in [6]. In this approach, a multiversion database is organized as a set of logically independent database versions. Each database version represents one state of the real world modeled by the database, either a consecutive state, or a variant. To this end, it is composed of one logical version of each object stored in the database. A database version constitutes a context for the logical object versions composing it. It is also a unit of versioning, i.e., no logical object version may exist out of a database version. The notion of consistency, de ned as the correspondence between a real world state and the database state, is now applied to database versions. The number of real world states represented by the whole multiversion database is equal to the number of database versions. The concept of database versions allows the use of transactions de ned as an extension of the classical de nition [11]: a transaction is de ned as a process that takes a set of database versions each one from a consistent state to another consistent state. We distinguish between object transactions and database version transactions (dbv -transactions). An object transaction operates on logical object versions within one or several database versions. Exactly as in a monoversion database, updating one or several logical object versions in a database version, an object transaction causes the evolution of the entire database version from one consistent state to another. A dbv -transaction operates on database versions. It creates a new database version or deletes an existing one. In the case of creation, it is addressed to a database version, the parent database version, and it derives a child database version, which, just after the derivation, is a logical copy of the parent. A database version may have as many children as required. Once created, the new database version will evolve autonomously, according to the object transactions addressed to it. Also the
parent database version may continue to evolve independently. We emphasize that, in general, there is no particular semantics associated with database version derivation, since the parent database version may continue to evolve. Of course, in a particular application, evolution of the parent database versions may be forbidden to associate a semantics with derivation. Since di erent database versions usually di er only partially from one another, often logical versions of an object have identical values. To avoid redundancy, they are mapped to a physical object version. As a consequence, a physical object version may be shared by several database versions. To identify database versions, i.e., to associate physical object versions with them, database version stamps have been introduced. They come from the observation that the most frequently a physical object version is shared by the database versions which are derived from one another. Thus, it is worth to organize a multiversion database as a hierarchy (tree) of database versions, even if each database version evolves autonomously, and even if a user perceives the multiversion database as composed of independent database versions. A database version stamp is constructed in such a way that it makes it possible to identify all the ancestors of the database version it concerns. If a database version is the n-th child of its parent, whose version stamp is p, then the child version stamp is p.n. The root database version is stamped 0. An advantage of this construction concerns derivation of a new database version. As \derivation" means \logical copy of the parent", the new database version stamp should be associated with the appropriate version (the one contained in the parent database version) of each object in the database. Version stamps permit to avoid explicit assignment, which would be inadmissibly long in large databases. Indeed, it is sucient to establish a rule saying that if no physical version of an object is explicitly associated with a database version, then this database version shares the
physical object version with its parent. The parent of a database version may be immediately identi ed, just by taking o the last element of its version stamp. The examples which shows how version stamps are used to associate version stamps with database versions are presented in [6].
4 Organization of Version Management In this section we present control data structures used to organize version management in the database version approach. To access and to manipulate logical object versions in database versions, four basic primitives are used: read, update, create or delete. If fact, there are two variants of updating and, by the consequence, of creation: in the rst one, the new value of a logical version of an object is directly given by a user; in the second one, it is assumed to be shared with another logical version of this object. Primitives use the pair (oid, vs), where oid is a multiversion object identi er, and vs is a database version stamp, to identify a logical object version. The version manager maps such a pair into the unique physical object version identi er vid. To this end, each multiversion object is equipped with, so called, Association Table. It is composed of two columns. In the left column, the version stamps explicitly associated with physical object versions appear, while in the right column physical object version identi ers are given. Thus, an entry of this table associates a version stamp with a physical object version identi er. It is important to note that the object identi er points to the association table. The structure of a multiversion object is presented in Figure 1. When a logical object version mapped to a shared physical object version is updated, or a new logical version of an object is created, its association table has
Multiversion Object oid
-
Association Table vs vid ? ? ? ? ? ? ?
physical object version
+
D
physical object version
D
D
D
D
D
D
D D ?
?
physical object version
D
physical object version
Figure 1: Multiversion object structure
to be updated by the version manager. To this end, the structure of the database version derivation tree must be known. It is maintained in the form of a table, called the DBV-Table. Each entry of this table corresponds to a database version, and for each database version the number of its children is stored. The DBV-Table is consulted when association tables are updated, and is updated when a new database version is created or a database version is deleted (dbv-transaction).
5 Concurrency Control There are three data structures that require locking in the database version approach, because they are common resources of transactions, namely, logical object versions, association tables and DBV-table entries. Object-transactions, which manipulate logical object versions, require appropriate locking all three of them; dbv -transactions, which manipulate (derive or delete) database versions, require locking only DBV-table entries. Following the classical two-phase locking protocol (cf. [5]), an object-transaction is processed in two phases: the locking phase and the commit phase. In the locking phase, it reads logical object versions from one or several database versions, and prepares their modi cations following from the update, create and delete operations in its private workspace. These modi cations are integrated with the database in the transaction commit phase. To read and modify a logical object version, an object-transaction must access the association table of its multiversion object, and its physical version. A dbv -transaction is composed of one operation only: either derive, or delete a database version. It is processed in one phase. From the logical point of view, a
dbv -transaction reads the entire parent database version to make a new database version as its copy. However, because of database version stamps, this reading and copying is reduced to the incrementation of the number of children of the parent database version in the DBV-table, and appending the child database version entry to this table. To delete a database version, a ag \deleted" is set in its entry of the DBV-table. In both cases, the only data structure accessed by dbv -transactions are DBV-table entries. One may expect three kinds of con icts requiring concurrency control:
1. Con icts between object-transactions addressed to the same database version; 2. Con icts between object-transactions addressed to di erent database versions that share some physical object versions; and 3. Con icts between object-transactions addressed to a database version and a dbv -transaction that is making a logical copy of this database version to create a new one. In fact, the second type of con icts, i.e. the con icts between object-transactions accessing two logical versions of an object, which are mapped to the same physical version, do not occur. In other words, any locks, including the exclusive mode locks, set on the same object by two transactions addressed to two di erent database versions are always compatible. Lock compatibility follows from the fact that locks are set on logical object versions instead of the physical ones. When a logical object version mapped to a shared physical object version is updated in one database version, then a new physical version is created and its value is modi ed, while the old one remains unchanged, kept for all the other database versions sharing it. Thus, no con ict occurs.
To solve con icts between object-transactions accessing the same database version, logical object versions accessed are locked in the shared or exclusive mode depending if they are read or updated. Concurrency control between transactions accessing the same database version in a multiversion database is exactly the same as concurrency control in a conventional monoversion database. To access object versions, objecttransactions need to use association tables, as explained in the previous section. So, an association table is a common resource for them. In the locking phase, they read only association tables. In the commit phase they may update them. To solve the read{ write and the write{write con icts on an association table, an object-transaction locks it in the shared mode in its locking phase, and in the exclusive mode in its commit phase. However, the locks on an association table have to be held only until setting on or o a lock on the object version. After this, they may be released, because the con icts are solved by locks on logical object versions. The nature of the con ict between an object-transaction accessing a database version and a dbv -transaction deriving a new database version from it is the following. To update association tables, an event which happens in the object-transaction commit phase when some logical object version mapped to shared physical object versions were updated, an object-transaction needs to know the number of children of the database version (database versions) accessed (cf. Section 3). To update association tables correctly, the number of database version children may not change until the association tables of all the objects accessed are processed, i.e. during the whole commit phase. This number may change only because of a dbv -transaction that derives a child database version (as we mentioned earlier, deletion of a database version consists in making it inaccessible, while its version stamp is not reused). To avoid a con ict between an object-transaction and a dbv -transaction, it is sucient to lock the DBV-table entry (entries) corresponding to the database version (database versions) accessed. As an object-transaction does not modify the DBV-table, it locks
it during its commit phase in the shared mode, while the dbv -transaction locks it in the exclusive mode. The locking schema of object transactions is shown in Figure 2. As may be seen, an object transaction in its locking phase, rst locks the association table of an object in the shared mode, then locks the logical object version it wants to access and then unlocks the association table. Association tables are locked to exclude their updates by concurrent transactions in their commit phase. Note that association tables are locked and unlocked separately one after another, so the access to one does not reduce accessibility of the others. They are locked for a very short time, just required to identify the physical object version and set a lock on the logical object version mapped to it. They may be concurrently accessed by other transactions in their locking phase. In the commit phase, an object transaction, rst, locks in the shared mode the DBV-table entries corresponding to the database version accessed. This does not exclude concurrent execution of several object transactions in their commit phases, since they never modify the DBV-table. This, however, excludes concurrent execution of dbv -transactions, for the reasons explained above. Association tables of the consecutive objects accessed by the object transaction are then locked in the exclusive mode which permits to modify them, i.e., to change mapping logical object versions to physical ones, and unlock logical object versions. Also in this case association tables are locked separately one after another, so processing one table does not reduce accessibility to the others. The schema of dbv -transactions is extremaly simple: to create a new database version composed of logical versions of all the objects, a dbv -transaction exclusively locks the DBV-table entry corresponding to the parent database version, increment its value by one, appends the child database entry to the table and unlocks the
DBV-table entry. The dbv -transactions are very short, so they do not delay the commit phases of object transactions. Note that dbv -transactions do not con ict with the locking phases of object transactions. As a consequence, a child database may be derived from the parent one, even if some object versions belonging to it are locked by an object transaction, due to the fact that physical object versions are modi ed only in the object transactions commit phase. The state of the child database version corresponds then to the state of the parent database version from before the beginning of the object transaction. This is a very important property of the database version approach, especially in CAD and CASE environments, where locking phases of object transactions are very long|they may last for hours and even days. If in such environment one user locks for long time some object versions in a database version, and in the middle of his work another user wish to access the same object versions in the same database version, he has the following choice: either to wait for object version unlocking and to succeed the work of the rst user, or to derive a child database version, work in parallel with the rst user and eventually merge the results. To illustrate the above protocol, consider rst two object-transactions T1 and T2 addressed to the same database version dbv and accessing the same objects. Assume that T1 has updated these objects, that it is executing its commit phase, and that it has processed some of the association tables of the objects accessed, but not all of them. Let T2 execute its locking phase. If it accesses an object, whose association table has been processed by T1, it gets it. If T2 tries to access an object, whose association table has not yet been processed by T1, then it nds an incompatible lock on the logical object version addressed and must wait. Consider now transaction T3, instead of T2. Let T3 be addressed to database version dbv di erent from dbv addressed by T1, and let physical versions of objects i
j
i
Locking Phase
Shared-Lock Association Table Lock Object Version Unlock Association Table
1st object accessed
? ? ?
Shared-Lock Association Table Lock Object Version Unlock Association Table
n-th object accessed
Commit Phase
Shared-Lock DBV-Table Entry (ies) Exclusive-Lock Association Table Unlock Object Version Unlock Association Table
1st object accessed
? ? ?
Exclusive-Lock Association Table Unlock Object Version Unlock Association Table Unlock DBV-Table Entry (ies)
n-th object accessed
Figure 2: Locking schema of an object-transaction
accessed by T1 and T3 be initially shared by dbv and dbv . Then, if T3 accesses an object, whose association table has been processed by T1, it gets the logical version belonging to dbv unchanged by T1. Since initially the physical object version was shared by dbv and dbv , T1 has prepared a new physical object version stamped with the version stamp of dbv , while the old physical object version, stamped with the version stamp of dbv , remained unchanged. Consider now T1 and T3, both executing their commit phases. Any order of processing association tables is correct, because update operations on association table entries are commutable. In this case, the shared physical object version mapping logical object versions from dbv and dbv , which were updated by T1 and T3, respectively, has to be spawn to obtain unshared physical object versions where changes are made. This is not a matter in which order the unshared versions are created. Consider now a dbv -transaction T4 addressed to the parent database version dbv . It cannot be executed when T1 executes its commit phase, because during the entire commit phase of a transaction the number of database children must be constant. On the contrary, T4 may be executed during the locking phase of T1. i
j
j
i
j
i
j
i
j
i
6 Conclusions The real reason why the solutions proposed up to date to version management in concurrently accessed databases were unsatisfactory was the lack of a proper model of multiversion databases and clear meaning of multiversion database consistency. The diculties came from the fact that multiversion database consistency is related to both versioning and concurrency. Without a proper model, apparent versioning viewed as a new functionality on the one hand and used as a tool to increase concurrency
degree on the other, was followed by management that was both complex and insucient. In the database version approach, the aspects of multiversion database consistency related to versioning and concurrency are clearly separated that is followed by perfect orthogonality of version management and concurrency control. The key point of this orthogonality is the distinction between logical and physical versions of objects, which has been introduced in the database version approach and does not exist in the others. In the other approaches, only the notion of a physical object version exists. In the database version approach, contexts are build over logical object versions, and concurrency control concerns logical object versions. In other approaches both contexts and concurrency control concern physical object versions. As a consequence, it is not possible to have a version of an object simultaneously exclusively locked in one context, shared locked in another one, and unlocked in yet another one. Thus, either transactions working concurrently on di erent contexts con ict, or redundancy is not avoided. In the database version approach there is neither redundancy nor con icts between transactions working on di erent contexts. Any kind of the concurrency control method could be combined with the version management proposed, not only two-phase locking. The combination proposed in this paper is very ecient. Real con icts arise only between two di erent objecttransactions addressed to the same database version. The nature of these con icts is exactly the same as in monoversion databases. Con icts between object-transactions addressed to di erent database versions and between object and dbv -transactions, in practice, will not arise. They concern only control data (association tables and the DBV-table), and may be solved by short waiting, because there is no danger of deadlock. In the database version approach there is no tradeo between versioning functionalities and concurrency degree. A database management system provides the users with rich
versioning functionalities: from a context that is a database version all the object versions may be identi ed, and from a physical object version all the contexts in which it appears may be identi ed. The use of version stamps permits to avoid searching in both cases and makes the identi cation immediate. A context is isolated from one another and maintained entirely automatically, so there is no danger of \side e ects" when object version updating. However, there is no redundancy, because common object versions are shared. Also changes may be easily propagated from a context to another simply by addressing a transaction to di erent database versions. Versions of an object appearing in di erent contexts may be easily compared, because a transaction may operate on several database versions simultaneously. Derivation of a new context is extremely ecient, because it is reduced to the incrementation of one counter. Finally, obsolete object versions may be easily removed from the database or archived without any danger of damaging useful contexts.
References [1] M. Adiba, Bui Quang Ngoc, Historical Multimedia Databases, Proc. 12th. VLDB Conf., Kyoto, Japan, August 1986 [2] D. Agrawal and S. Sengupta, Modular Synchronization in Multiversion Databases: Version Control and Concurrency Control, Proc. ACM SIGMOD Int. Conf. on Management of Data, Portland, Oregon, in SIGMOD RECORD, Vol. 18, No. 2, June 1989, pp. 408-417. [3] O. Bensadoun, C. Chrisment, G. Pujolle, G. Zur uh, Dynamic aspects of document databases, Cinquiemes Journees Bases de Donnees Avancees, Geneve, Suisse, September 1989 (in French).
[4] Y. Bernard, M. Lacroix, P. Lavency, M. Vanhoedenaghe, Con guration Management in an Open Environment, 1st European Software Engineering Conf., Strasbourg, France, September 1987, pp. 37-45. [5] W. Cellary, E. Gelenbe, T. Morzy, Concurrency Control in Distributed Database Systems, North-Holland, Amsterdam, 1988, 349 pages. [6] W. Cellary and G. Jomier, Consistency of Versions in Object-Oriented Databases, Proc. 16th. VLDB Conf., Brisbane, Australia, August 1990, pp. 432441. [7] W. Cellary, G. Vossen and G. Jomier, Multiversion Object Constellations: A New Approach to Support a Designer's Database Work, accepted for publication in Engineering with Computers, Springer Verlag, 1994. [8] Hong-Tai Chou, Won Kim, A Unifying Framework for Version Control in a CAD Environment, Proc. 12th VLDB Conf., Kyoto, August 1986, pp. 336-344. [9] Hong-Tai Chou, Won Kim, Version and Change Noti cation in an ObjectOriented Database System, Proc. 25th ACM/IEEE Design Automation Conf., Anaheim, June 1988, pp. 275-281. [10] K. R. Dittrich and R. A. Lorie, Version Support for Engineering Database Systems, IEEE Trans. on Soft. Engineering, Vol. 14, No. 4, April 1988, pp. 429-437. [11] J. Gray, Notes on Data Base Operating Systems, in: R. Bayer, R. M. Graham and G. Seegmuller (Eds.) Operating Systems: An Advanced Course, Springer Verlag, Berlin, 1978, pp. 393-481.
[12] T. Haerder and A. Reuter, Principles of Transactions-Oriented Database Recovery, in: M. Stonebraker (Ed.) Readings in Databases Systems, Morgan Kaufmann Publishers, 1988, pp. 151-166. [13] R. H. Katz, E. Chang, Managing Change in a Computer-Aided Design Database, 13th VLDB Conf., Brighton, UK, 1987, pp. 455-462. [14] R. H. Katz, E. Chang, R. Bhateja, Version Modeling Concepts for ComputerAided Design Databases, ACM SIGMOD Int. Conf. on Data Management, 1986, pp. 379-386. [15] J. R. Nicol, G. S. Blair and J. Walpole, A Model to Support Consistency and Availability in Distributed Systems Architecture, Proc. IEEE Workshop on Future Trends of Distributed Computing Systems in the '90s, Hong Kong, September 1988. [16] W. F. Tichy, Tools for Software Con guration Management, Proc. 11th International Conference on Software Engineering, May 1989. [17] J. Walpole, G. S. Blair, J. Malik, J.R. Nicol, A Unifying Model for Consistent Distributed Software Development Environments, SIGPLAN Notices, Vol. 24, No. 2, February 1989. [18] S. B. Zdonik, Version Management in an Object-Oriented Database, Int. Workshop on Advanced Programming Environments, Trondheim, Norway, June 1986.
