deposit_hagen
Publikationsserver der Universitätsbibliothek
Mathematik und
Informatik
Informatik-Berichte 82 – 08/1988
Peter Klahold, Gunter Schlageter, Rainer Unland, Wolfgang Wilkes
A transaction model supporting
complex applications in integrated
information systems
in integrated information systems
Abstract
P. Klahold, G. Schlageter R. Unland, W. Wilkes
University of Hagen Postfach 940
D-5800 Hagen West Germany
The use of database systems in new applications, e.g.
computer aided design, software engineering, etc, leads to new requirements for the transaction management. Main characteristics of such environments are lang duration of transactions and teamwork.
In this paper we introduce a concept for lang transactions which especially supports the cooperative work of groups an a common set of data. The transaction model has two levels:
an the one hand the team has tobe protected from the outside world, on the other hand mechanisms are required which allow controlled teamwork on common objects. In the latter case rigid synchronisation mechanisms as used in database systems are not applicable.
A main concept for the support of teamwork and for design databases in general is a user-oriented version mechanism.
This paper presents such a mechanism and its integration into the transaction model.
1. INTRODUCTION
Fields of application as CAD/CAM, office automation, software development, etc., more and more require support by database systems. Conventional database technology, however, was principally designed for commercial usage and therefore supports such new environments only incompletely.
This paper deals with one of the major problems of new database applications, the support of lang transactions in cooperative environments. With such transactions, groups of users work cooperatively for weeks or months an a comparati- vely !arge, common set of data.
Solutions for lang transactions published so far, for example /HaloBl, LoP183, KaWe83/, only allow objects tobe assigned to individual users for a certain period of time.
They da not consider environments in which users work cooperatively to fulfil a common aim.
This paper introduces a concept for lang transactions which particulary supports users working cooperatively an a common set of data. The transaction model has two layers: firstly, the users are to be shielded from the outside, secondly, mechanisms are tobe supplied to allow controlled coopera- tion an common objects within the group. For the latter, rigid synchronisation mechanisms as used in current database systems are not suitable. (In fact, the transaction model can easily be generalized to a multi-layer model; because of the space available we just present the main idea in the form of a two-layer model.)
Concepts of versions and alternatives, as essential elements of development processes, have been integrated into the transaction model. lt will be shown that this mechanism increases the flexibility of the transaction management, especially with respect to parallelism. As a consequence, new locking mechanisms had tobe developed, particulary, because modifications of an object cannot only be updates of its values but also derivations of versions.
An overall scheme for lang transactions has to integrate various aspects which by themselves are topics of research.
Of course, we cannot give detailed solutions for all problems relevant in this context. The main purpose of this paper is to present a framework for a complete solution, and to discuss some selected points more in detail.
2. NEW REQUIREMENTS fOR THE TRANSACTION MANAGEMENT Complex applications of the above outlined type operate on a relatively large and fixed number of objects for a lang period of time. The functions which are tobe performed can be divided into individual units which only require a subset of the objects.
Typically, groups of users work on the solution of design- problems (CAD, software development, etc.). Each member works on a well-defined part of the problem within the environment. The members of the group work cooperatively, rather than competitively, they coordinate their work. In particular, the users know to what degree their work overlaps and wether they may proceed in parallel without endangering the consistency of the common data or not.
An environment of this kind therefore requires not only synchronisation of the users' transactions - as in contempo- rary systems - but, moreover, it has to support cooperation within groups of users. We regard the work of the group as a transaction, where the objects dealt with by the users are consistent at the beginning and at the end, since a correct synchronization is guaranteed by the database system. Within the group transaction the individual users start their own transactions, called user transactions in the sequel.
In our opinion, the system should enable the users to war~
with the flexibility they have today, which means, that the way of reasoning must be how we can offer this flexibility but with more safety and better support. Essentially, the user should be able to influence the setting and releasing of locks to cooperate and communicate in a more flexible way with the other members of the group. Of course, if the users make use of these possibilities, the transaction management cannot completely guarantee consistency within a group transaction in the sense of serialization of the user transactions.
Not surprisingly, these general requirements for the transaction management lead to specific requirements for the locking mechanism.
Another major requirement is the provision of a flexible version mechanism for the documentation of the design process and for the management of the design alternatives.
As will be seen there are interconnections between transac- tion management and version management.
To meet the above requirements the following mechanisms have tobe integrated:
multi-level transaction management (two-level in this paper) with appropriate locking mechanisms
- version mechanism supporting alternatives
3. THE GROUP ORIENTED TRANSACTION MODEL
A system to handle lang transactions working on a relatively fixed number of objects was described in /Haloßl/ and /LoP183/. Similar ideas can be found with other authors
(e.g. the "library"-model in /KaWe83/).
According to these proposals updates are not performed directly in the public database, but in a private user database. Complex objects are copied from the public database by CHECKOUT into the user s database. When the transaction is finished (after days or even weeks), the modified objects are restored into the database by CHECKIN.
Long-living locks are imposed on the objects, checked out from the public database. Other transactions can read these objects in the state before the checkout.
•
public DBprivate DB
[SJ
locked object Fig.l: Transaction model of /Haloßl/The CHECKOUT/CHECKIN model offers the following advantages:
- the object can be read in its former state in parallel to a user's activity.
- the modification of an object is performed in a private space, perfectly invisible to other users.
- the only critical phases with respect to the concurrency
control of the whole transaction are the operations CHECKOUT and CHECKIN.
This model is fully appropriate when users work in an isolated manner an objects of the public database. However,
i t does not sufficiently support those (many) environments
where users da cooperative work an a common set of objects.
Ta support this continual process of cooperation within the group, the members of the group must be enabled
- to make incomplete results visible to other members of the group,
- to apply other members' their own problem,
intermediate results to solve
- to pass an intermediate results directly to the colleagues to enable them to continue their work.
to work objects,
in parallel for instance
to others an the same set of basic to produce alternative soluttons.
These requirements lead to a group-oriented two-layer transaction model with group transactions (GT) and user transactions (UT). Any user transaction is a subtransaction of a group transaction. The group transaction provides the environment for the work of the group, i t establishes a sphere of production and control for the group; the work of the users is done within user transactions which are started and terminated within the group transaction (see Fig.2).
•
public DBGT
group DB
UT
private DB (workspace)
Fig.2: Representation of the two-layer transaction model
The following holds:
(1) The GT is assigned to a group of users.
(2) The GT operates an the public database like transactions in the CHECKOUT/CHECKlN model, that is, it copies objects from the public database into the group database and restores them later an. Long-living locks are set in the public database by CHECKOUT. GTs are well-formed and two-phase and therefore serializable.
(3) For each GT a group database is established. The group database corresponds to the user database of the CHECKOUT/CHECKlN model, that is, it is a temporary database and exists only as lang as the GT exists. lt represents the working environment for the group, i.e.
for the user transactions (UTs). The group database can only be seen by the UTs and the GT itself, other transactions have no access to it. The potential parallelism of the UTs renders it necessary to apply concurrency-control mechanisms in the group database.
(4) UTs are subtransactions of the GT in the sense that they can only influence such objects which have been checked out of the public database by the GT and are, therefore, in the group database. They operate in parallel to each other, are well-formed and - unless the user intervenes two-phase. But they allow users to influence the concurrency control. Like the GT, they aquire objects by CHECKOUT, however from the group database.
(5) The objects of the UT are manipulated in the private workspace or the private database of each user.
Organization of a transaction
According to this model, a transaction typically runs in the following way (the syntax used in the following is examplary and shall help the reader to realize the semantics of the commands):
Since GTs are assigned to groups of users, the group must be introduced to the system by:
CREATE_USER_GROUP <group_name><user_id_list>.
lt can be modified at any time - even during a GT - by:
CHANGE USER GROUP <group_name> ~DD J<user_id_list>.
~EMOVE
The group (or any membe , respectively) can start one or more GTs:
BEGIN TRANS <GT name> FOR <group_name>
At the same time the group database is created. The GT can only be active an behalf of one member of the group at a time. The user who has control of the GT can make it copy objects from the public database to the group database by CHECKOUT and finally update the public database by CREATE_
VERSION or UPDATE_VERSION (see chapters 4,5). The initiator of the GT has control of it until he either starts a UT or explicitly suspends the GT. Taget control of the GT a user has to suspend his UT explicitly and call the GT (note that the group transaction is only used for communication between the public and the group database; the designer works with the user transaction). For this purpose, SUSPEND and CONTINUE operations must be provided.
SUSPEND suspends the transaction currently active for the user (GT or UT)
CONTINUE TRANS <GT name> reactivates the GT
CONTINUE TRANS <UT name> WITHIN <GT name> reactivates the specified UT.
As soon as the GT is initiated, the members of the group can initiate UTs, which run in parallel to each other.
BEGIN TRANS <UT name> WITHIN <GT name>
A user may run several UTs at the same time. This enables him to work on different objects simultaneously, and to use the UTs alternatively (by suspending one UT and activating another one).
Since the UTs are running simultaneously, appropriate concurrency-control mechanisms must be applied an the group database level. The checkout of objects from the group database to the private database involves locking of objects in the group database. However, because of the cooperative behaviour of the group members, mechanisms for explicit relaxation of two-phase locking are provided.
A UT is finished by END TRANS.
When the group has reached its aim, the results (as well as any intermediate state the user wants to make visible to others) are written into the public database by activation of the GT. The GT is also finished by END TRANS.
4. VERSIONS
Ta meet the special requirements of design environments and to allow a higher degree of parallelism between user transactions, a version concept is introduced which aims at:
- fixing the design process (documentation) - allowing redesign from a previous version
- enabling the system to manage alternative designs - allowing parallel updates an an object
- informing the group of users immediately of (intermedia- te) result of user.
For the purpose of this paper we introduce a version model based an the notion of a version graph. Since our aim here is transaction management, we da not consider more advanced models supporting all kinds of versions and intra-object relationships (for instance between different representa- tions of an object as in /Neum83/ or /Katz84/).
What a version is, is defined by the user: a user works with an object A, and at some point of time he decides to create a new vers~on of A. Call the original version of A vO(A), the new version vl(A). Creation of versions in the system is done by a CREATE VERSION command. The version vO(A) and vl(A) represent the same semantical unit of the user's world in a different state.
The convential notion of versions as "the series of states of an object over time" is not sufficient here. Therefore, we introduce a version graph VG; the nodes v
•, •...
,vn are the versions, and the edges show the derivation path, that is, edge (vl,v2) indicates that v2 was derived from vl. The graph has one root and is acycli~The object usually the are kept).
graph has a name in the user's world (which is name of the semantical unit for which versions Thus, the version graph is also a named object.
There is no need for a separate notion of alternatives:
alternatives are just versions with the same father node (or set of fathers).
+----+ +----+
+----+
+---->!
+----+
+---->! !---->! !---+
+-~--+ +----+ !
+----+
+----+
!---+ +---->!
+----+ ! +----+ +----+ +----+
+---->! !---->! ! +----+ +----+
Fig.3: Version graph
4.1 Manipulation of Versions
In principal, the user can modify existing versions or
delete versions or create new versions.
The modification of a version only changes the specified node, whereas deletion or creation of versions changes the structure of the version graph, but leaves all other versions untouched.
Creation of a new version
The following command allows the creation of a new version:
CREATE VERSION <v> NAMED <vers name>
v is a pointer to the new version v which is tobe integra- ted into the graph specified in the FOR clause. A unique version identifier is assigned by the system; in addition, the version can be given a user defined name. The AS SUCC OF clause specifies the versions which are the predecessors of
V•
In practice, merging of versions may be an important issue.
Several users may want to work in parallel on one node v of the graph; to do this they produce a set of successors vl, ••• ,vn of v. Lateran, the users may wish to produce one version vg derived from vl, ••• ,vn. This merging of versions
cannot be done by a generalized version management, of course, but has tobe done by the application level or by the users themselves.
+----+ +----+
+---->! !--->! !---+
+----+ +----+
+----+
!----+
+----+
+---->!
+----+ ! +----+
+----+
+---->! !--->+
+----+
Fig. 4: Merging of versions
Hodlfication of an existing version
The following command allows to modify an existing version:
UPDATE VERSION <v> FOR •
L
graph_namej ~vers_namej<graph_id> <vers_id>
The parameters identify the version which is tobe modified.
UPDATE VERSION may only be performed an the leaves of the version graph, because changing the inner nodes would also affect the versions derived in the meantime. There are possibilities to manage such propagating updates, e.g. by notification mechanisms; this is not treated in this paper.
Deletion of a version
The deletion of versions allows the users to thin out the version graph. This is particularly useful for the genera- tion of a version graph for documentation purposes. Fre- quently, the importance of an intermediate step for the further development can only be estimated afterwards. The command DELETE allows to eliminate versions from the version graph which are not wanted any more.
b
graph namej DELETE_VERSIONgraph_id>
. f
vers_name1~vers id>
J
connects all versions derived from the version v, which is tobe deleted, with all predecessors of v.
We would like to point out an important aspect here. The
creation of a new version as well as the modification of an existing one, is a lasting fact, i.e. changes of the version graph cannot be made ineffective implictly by resetting the transaction. The only possibility is a reset under the user's control by explicit version operations.
4.2 Version graphs in the two-layer transaction model In accordance with the two-layer transaction model, we have to distinguish two version graphs for a semantic unit:
public database level group database level
global graph of public versions local graph of group versions
The main function of the local version graph is to enable communication within the group of users and short-term documentation within a lang transaction. Therefore it will generally show more details, i.e. more versions, than are of interest for the public database.
By CHECKOUT a GT copies an individual version of the global version graph from the public database into the group database. This copy forms the root for local version graph
(see fig. 5a).
The local graph is modified by UTs until the group has reached its aim. In order to save the result, it has tobe transferred into the public database. This is realized by activation of the GT (CDNTINUE_TRANS) and the appropriate CREATE VERSION or UPDATE VERSION commands.
public DB
GT: CHECKOUT
group DB
( a )
0
GT: CREATE VERSION
UTs
Fig.5: Global and local version graphs
VERSION
(b)
Constraints for local version graph manipulation Constraints for admissible operations:
A version v is checked out from the public database with a certain lock specified by GT. This .lock determines which operations are permissible an v for the members of the group. For instance, i f a version was checked out for reading only, it may not be modified by any member of the group. The set of permissible operations is derived from the ''is-stronger-than" graph (see chapter 5.2).
Update constraint:
If a version v of the local graph was already entered into the global version graph by the GT through CREATE_VERSION or UPDATE VERSION any further update of v in the local version graph destroys the consisteny between the local and global graph. Therefore, a safe update constraint for the local graph is, not to allow any modification of a version after it has been written to the public database.
One may weaken these strict rules by prohibiting only some operations and giving warnings in other cases. We skip this possibility here.
5. LOCKING MECHANISM
Similar to the GTs operating in parallel to each other an the public database, the UTs work in parallel on the group database. Thus means to control simultaneous access must be taken an both transaction levels. The locking mechanisms of current databases are not sufficient for our purposes, an extended locking scheme is required.
5.1 Lock types
A lock on an object always has two meanings:
(1) the owner-transaction of operations (to perform an acquired a suitable lock)
the lock may perform certain operation you must have
(2) other transactions are limited as to the operations they can perform an the locked object (compatibility of locks)
In the presence of versions as defined in chapter 4, we have to consider three operations:
- reading of a version
derivation of a new version modification of a version
Deletion needs no explicite treatment in our model. Problems can arise only in case of traversing a graph. The necessary locking of predecessors and successors of the node tobe deleted is tobe done by the system with setting short-term locks. This is not considered further here.
lt is clear that the modification of a version v and the derivation of a new version both require the original version tobe read. Thus, the right to modify a version, or to derive a new one always includes the right to read.
Moreover, the right to modify a version always includes the right to derive new versions from it.
In spite of the three operations, you may, at a first glance, suppose two locks to be sufficient as with conventional database systems: when a version is read, or a new version is derived, the main aim is to prevent the original version from being modified. The version model allows parallel operations of users reading and deriving new versions. Moreover, it does not exclude the possibility that different transactions derive successors to a version simultaneously. Consequently, we could define a R-lock (shared-lock) which does not only allow reading of versions, but also deriving of new versions, and only excludes updating.
Unfortunately, the conventional R-lock, X-lock scheme is not sufficient: the derivation of a version also represents an update operation, namely to the version graph; the structure of the version graph is modified. Thus, it is desirable to enable a transaction to exclude others from simultaneously deriving new versions from an existing version v; other transactions may only read the version v. According to the three operation modes we need a third lock mode: the D(erivation) lock. Note that in the case of purely time- oriented versions this ''exclusive derivation mode" is the only mode the system knows.
In our locking scheme we split the D and R lock with respect to the rights other transactions have: In one case others are only allowed to read the locked node, in the other case they may derive new versions of it, too. Thus, there are five basic lock modes:
R-lock: - allows the owner to read - allows others parallel read RD-lock: - allows the owner to read (say v)
- allows parallel read and derivation (from v) DS-lock: - allows the owner to read and to derive
- allows parallel read and derivation DX-lock: - allows read and derivation
- allows parallel read
X-lock: - allows read, modify and derivation - no parallel operation allowed
DX-lock (D-excluxive) is necessary to allow exclusive derivation. Ta allow parallel derivation the DS-lock (D-shared) is applied. For reading without parallel deriva- tion the R-lock is introduced. (Of course, a frozen state can also be read by applying X- or DX-locks, however this would prevent parallel reads). If parallel derivations should be allowed, the RD-lock is applied. (Again, a DS-lock could be used; however, read in parallel to exclusive derivation would not be possible then.)
The compatibility matrix is as follows:
Due to versions
RD R DS
RD X X X
R X X 0
DS X 0 X
DX X 0 0
X 0 0 0
the two dimensions (derivation)" the
DX X
X 0
0 0
0 0
0 0
0 0
"version" and locks da not
"relation between form a total order in the sense conventional locking schemes da. We have to make a clear distinction between "outward" effects, i.e. the rights remaining for other users once the lock is set, and the "inner" effects, i.e. the rights given to the owner of the lock. For instance, DS and RD only differ in what they allow the owner of the lock, whereas other transactions are entitled to the same operations, i.e. to read and to derive.
On the other hand DX and DS locks grant the owner the same rights and only differ in what they allow other transac- tions. The differentiation of these locks is essential, however, for the potential parallelism.
5.2 Lockmode conversion
A command to convert a lock might have the following form:
FOR
h
graph_namej . Lvers_name>]CHANGE LOCK _ TO
RO R OS DX
X
<graph_id> <vers_id>
lt is mandatory to know which conversions are compatible with the two-phase protocol, i.e. which conversion weaken and which ones strengthen a given lock. According to the
"outward" and "inward" effects of the locks, the following partial order can be applied:
A Sl type lock is stronger than a S2 type lock (51 type<>
S2 type)
<===>
Sl grants the owner the same rights or more rights than S2 and
Sl grants other transactions less rights or the same rights than S2.
This definition yields the following "is-stronger-than"
graph:
Fig.
lt is other, This
+---+
! X ! +---+
! +---+
+--- !
D
! ---++---+
! R ! +---+
!
+---
+---+ !
+----+
!
DD
! +----++----+ !
! RD ! ---+
+----+
6: "is-stronger-than" graph
Lock 51 is stronger than lock 52 <==>
Sl is above S2. Alternatively we say S2 is weaker than Sl.
remarkable that Rand OS cannot be compared with each i.e. R is neither stronger than OS nor vice versa.
is due to the fact that R is stronger than DS with
regard to the outward effect, but less strong as far as the inner effect is concerned.
In order to enable the system to check the two-phase status of the transactions, locks must only be converted along the edges of the "is-stronger-than" graph.
A precise formulation of the constraint for admissible operations (see chapter 4.2) can now be given:
If version v is checked out from the public database with lock Sl, then a member of the group can apply to v opera- tions requiring locks of the type Sl or weaker locks as defined in the "is-stronger-than" graph.
5.3 Access to versions
Checkout of versions
The locks are set when a version is acquired via the CHECKOUT command:
CHECKOUT
j<graph_name1 Jpvers_name~ .. ·]
1WITHGgraph_id>
J
~vers_id>J
RD R DS DX
X
If this command is called from a group transaction, the specified versions are copied into the group database with the appropriate locks set in the public database. Called from a UT, CHECKOUT copies the versions from the group database into the private database of the user. A lock is set in the group database. Of course, the command is only executed if none of the specified versions is locked by an incompatible command.
Reading with low-level consistency
In order to avoid unnecessary delay of those users, who can live with inconsistencies in the data
reading special
READ
of locked versions is allowed READ command:
rgraph_nameJ Lgraph_id>
Jf<vers_name] ... l
~vers id>
J
( e. g. browsers), at any time by a
READ does neither observe nor set locks. However, the user is informed an the locks of every version he reads. This
enables him to draw conclusions as to the consistency of the version.
5.4 Release mechanisms
Differences between the GT and its UTs da not exist as to the the setting of-locks, whereas there are differences as to the releasing. Since the group database, above all, serves as a medium of communication between the members of the group, the release mechanisms for the group database should be more flexible than for the public database.
Release of set of versions
The release of (parts of) a version graph is realized by the command RELEASE:
b
graph_id>J
RELEASE
graph_id.vers_id>
This command releases all versions a transaction has locked in the version graph "graph_id" or the specified version
"vers id".
Release of locks in GT
The GT operates an the public database and has tobe two-phase. For this reason the following rules hold for the conversion of locks in GTs:
(1) Locks may only be strengthened in the acquisition phase.
(2) Lacks may only be weakened in the release phase.
It is customary that transactions release modified objects only at EDT to avoid propagated rollback. This restriction does not apply to the given environment, i.e. versions may be released at any time within the release phase. However, as mentioned in chapter 4.1, the group cannot undo a CREATE VERSION or UPDATE VERSION implicitly (i.e. by undoing the transaction), thus avoiding propagated rollback.
On newly created or updated versions a X-lock is automati- cally set. Thus, if no lock is weakend, modifications of the global version graph (UPDATE_VERSION, CREATE_VERSION) become public only with the release of the versions, or with the end of the transaction.
With this concept, the group can enter important subresults or completed parts of the problem into the public database by CREATE_VERSION early. However, these versions are neither accessible to other users for further processing, nor made visible as a final result without explicit intervention of the user (weakening or releasing of locks). In this case other GTs can only read a new version by READ and know accordingly that the version may be inconsistent with regard to other objects of the database. If other GTs are tobe excluded from this possibility of access, appropriate means of access control have tobe applied.
Release of locks from UT
The following aspects are important for UTs:
UTs are well formed (acquisition of appropriate locks before access), however, they are not necessarily two-phase. Lacks can be released or weakened at any time.
Due to the weakening of the strict two-phase lock protocol for transactions, the users get a high degree of flexibi- lity; of course, the prize is that the system can no langer guarantee consistency if users make use of this flexibility.
As in the public database newly created versions are X-locked. The user may change the lock explicitly if he whishes. Thus the UT is two-phase in general, as lang as the user does not intervene.
5.5 Unsuccessful lock request
With usual lock operations, transactions facing locked objects are put into a waiting state. Since objects can be locked for a considerable period of time in this environ- ment, waiting is not appropriate.
If a transaction requires an object which is already locked in an incompatible mode, the request is rejected. Thus, an intrasystem waiting state is avoided, and consequently, a deadlock as well. The user decides (e.g. after having asked the current owner), whether he wants to continue his work without owning the requested object, whether he should wai~
for its release, or whether he wants to stop his transac- tion. In many cases it may be useful to have the system inform the user when an object he requests is available.
5.6 Lock granularity
So far we assumed that unit of locking is the version. The selection of a version as a lock granule is natural as this corresponds to the usual operation mode of the designer and therefore also offers a high degree of parallelism.
Different operation modes, however, require coarser lock granules. This is always the case with users being unable to specify the required version, exactly, if a user intends to work on large parts of the version graph.
The following example illustrates the necessity of a coarser lock granule. A transaction TR is to read all leaves of a version graph with consistency level three. lt would be insufficient to run through the graph and to lock the existing leaf nodes, because another transaction TD could be operating at the same time deriving a new version from an inner node of the graph. TD would produce a new leaf node during the operation of TR and would consequently lead to a phantom problem for TR. This problem can only be avoided by locking the complete version graph.
Between the two extreme lock units (version lock, graph lock) a medium size lock granule would be desirable. If the transaction TR only requires the leaf nodes of a certain subgraph of the version graph, it would be effective to lock only the required subgraph which could be specified by its root. Since the complete version graph can be locked in this way (by denominating its root), the following lock command is introduced:
~
graph_namej ~vers_namej
LOCK STARTING FROM WITH
graph_id> <vers_id>
X D DD R RD
The command locks the specified version and all its succes- sors in the version graph in the specified mode. If a node of the subgraph is already locked in an incompatible mode, the lock request is rejected.
This kind of lock allocation favours the request of indivi- dual locks, because the costs of setting a lock depend on the number of versions to be locked. In case that large parts of the graph are locked frequently locking strategies using intention locks are more suitable, but are not discussed here.
The introduction of the command LOCK enables the user to adapt the lock granule to his particular requirements, and it allows the correct synchronization with a high degree of parallism in all situations. If the user wants to operate an certain versions these are implicitly locked with the command CHECKOUT. If he does not know the required versions in advance, he can lock the corresponding subgraph, thus determining the size of the lock granule to meet his particular requirements.
6. TRANSFERRING VERSIONS BETWEEN USERS 6.1 Lending of versions
Due to the duration of locks, a user Ul can be excluded from the operation on a version v, although the user U2, who has set an exclusive lock an v, does not work an v at present.
As lang as Ul does not disturb U2, an alternating work of Ul and U2 an v should be enabled, with either Ul or U2 working at one time. For this purpose we suggest the concept of lending of versions. With the lending of a version v to a user Ul, all rights are assigned to the borrower Ul, except the right to transfer the version into the group database (CREATE_VERSION, UPDATE_VERSION). As soon as Ul has finished his operation, he returns the control over v to the owner of the lock, i.e. to U2.
The lender uses the operation
GRANT <v> NAMED <name> TO <user id>
Grant makes the version tobe lent available to the user
<user id> in its present state. The user can copy the borrowed version into his private database by
FETCH <name> FROM <user id>
When the borrower the modified version
RETURN <v>
has finished his operation, he releases by
for the original owner, who can fetch back the version (by FETCH) to his private database.
6.2 Transfer of versions
If the owner of a version is not interested in getting the version back later, (e.g. another user continues his working unit), he can transfer it to another user. The receiver of the version subsequently may work with it at will, espe- cially, he may rewri~e the version into the group database.
The transfer is realized by:
PASS <v> NAMED <name> TO <user id>
The adressee once again has access to the version released for him by the command FETCH.
6.3 EOT processing
The following principle is applicable to versions borrowed or checked out: only the versions which are rewritten explicitly (RETURN, CREATE_VERSION), survive the end of the transaction. EDT processing must consider this principle:
In case that the transaction has lent individual versions to other users by GRANT and did not get it back, END_TRANS will be rejected, since the versions lent could not be written into the database. Every version the transaction has borrowed of other users by FETCH and which has not been returned yet, is returned at END TRANS. In this case the performed modifications are void, and the version is returned in its original state.
7. CONCLUSIONS
This paper introduced a transaction concept tailored to the requirements of design environments, in particular the support of cooperative work. On the level of the public database it guarantees the safety known from conventional databases and realized by a two-phase transaction model.
Within the groups it offers means for communication and cooperation, thus giving the individual user more flexibi- lity. It has been shown, how a version concept can be integrated into the transaction model and how advantageous it can be for the cooperating work of the group.
This paper is meant tobe a framework and a starting point for an overall solution, and not a detailed solution to all problems of interest in this context.
A crucial point of the concept is the group database. The
members of the groups are responsible for the correctness of the group database versions. Since the group database serves as a medium of both communication and documentation, the same "internal" consistency, i.e. the same degree of development, cannot always be expected with its versions.
In order to make the state of a version clear, there are at least two possibilities:
1. Classification of versions. A specific degree of consi- stency with permitted subsequent operations is assigned to each class of version (by the group of users).
2. Information board. Every version is supplied with a board an which the users stick information an actual state of the version and recommended subsequent operations.
The first way is more restrictive than the second: the conditions corresponding to the version type, and, moreover, the subsequent ·operations have tobe determined right at the start. Information an the board, however, is text formulated at the moment the version is created. The system cannot see to it, though, whereas it can garantee that the rules combined with the individual version types are satisfied.
The application of both kinds of information transmission seems to be quite efficient, with 'general consistency conditions being made known by version standardization, and specific information being transmitted by means of the board.
"Intermediate versions'' are examples of special version types. The period of processing of objects in the user's workspace can be as lang as the designer chooses. If no new group database version is generated during the time of processing, other group members cannot obtain a more current state of the object. The user holding the object could enter a version marked as "intermediate" into the group database, thus informing all readers that the version is only prelimi- niary and possibly has a low degree of consistency. Instead of setting locks explicitly, the restriction of operation - modes could be directly related to the type of the version.
An important aspect of a transaction model for design environments is a concept for saving the work done by the designer. Because the transactions are much langer than in conventional database systems, the transaction cannot be the unit of recovery in our model. Instead it is necessary to restart unfinished user transactions and to bring them back to a state as near as possible to the crashpoint.
This can be done by transaction-oriented savepoints which save states of a transaction (either an user demand or automatically). On the other hand we have version-oriented savepoints, which support the trial-and-error process of the user: he is able to introduce such a savepoint explicitly for a specified version. Thus, the user may reset parts of his transaction by re_using a former state of some object he works with, while the other objects remain in their last state. There is no space here to discuss the relationship between these kinds of savepoints in detail and to present an integrating concept.
Finally, as already mentioned, the concept described in this paper can be generalized to a multi-layer model. By introdu- cing further levels of group databases, the model can easily be adapted to any real-world design environment, which, in fact, are hierarchical in nature quite often.
A main point for further research is the generalization of the concept with respect to composed objects and more sophisticated version models. Work is underway to investi- gate the problems introduced by these more complex structu- res and to generalize the proposed transaction model appropriately.
B. LITERATURE /EGLT76/
/GLPT76/
/Gray78/
/Halo81/
K. p. Eswaran, J. N. Gray, R. A. Lorie, I. L. Traiger
The notions of consistency and predicate locks in a database system
Comm. ACM 19, No. 11, Nov.76
J. N. Gray, R. A. Lorie, G. R. Putzolu, I. L. Traiger
Granularity of locks and degrees of consistency in a shared database
Modelling in Database Management Systems, G. M. Nyssen (ed.), 1976
J. Gray
Notes an database operating systems
Operating Systems, Lecture Notes in Computer Science 60, 1978
R. L. Haskin, R. A. Lorie
On extending the functions of a relational database system
IBM Research Report RJ3182, 1981
/KaWe83/
/Katz84/
/LoP183/
/Neum83/
R. H. Katz, S. Weiss Transaction
Computer
management for design databases Sciences Department, University of Wisconsin-Madison
Technical Report No.496, 1983 R. H. Katz
Information management for engineering design to appear: Springer-Verlag Surveys in Computer Science Series
R. A. Lorie, W. Plouffe
Complex objects and their use in design transactions
Engineering Design Applications, Database Week San Jose 1983, p. 115-121
Th. Neumann
On representing the design information in a common database
Engineering Design Applications, Database Week San Jose 1983, p. 81-87
H ~ , ,·•
.J ... , ' ' • ' /
