On detecting conflict between proposed updates

In the Heraclitus paradigm, a delta value or more simply, delta, is a concrete value that corresponds to a difference between database states. This paper presents the Heraclitus[OO] (abbreviated H2O) DBPL, which provides a syntax and semantics for working with deltas in the context of object-oriented databases. The paper also considers the use of deltas in connection with detecting conflict between pairs of proposed updates to a database. This is useful in contexts where multiple users are each creating and choosing between multiple possible updates. A semantically based notion of potential conflict between proposed updates is developed, along with several conservative approximations based on the use of different kinds of delta.


Introduction
There are a variety of application areas involving the creation and analysis of complex updates that may or may not be applied to the database.This frequently arises in systems that support the delivery of complex services (e.g., telecommunication or transportation services to corporations).In these contexts, the proposed updates are characterized by the following: Long duration -Multiple, potentially conflicting, updates may be in progress for extended periods, perhaps days or longer.The partial updates may need to be accessed and modified multiple times.
Hypothetical access -Many of the updates may never actually be applied to the database.For example, a customer may explore different possible changes to their service.It is useful to access and compare the hypothetical database states corresponding to the application of different proposed updates.
Potential conflict -Updates proposed by different users might conflict with each other, e.g., because they modify the same object.Moreover, the very notion of conflict and how to resolve it is typically dependent on the application.
In this paper we develop a versatile framework for creating and managing multiple long duration proposed updates, and for efficiently detecting potential conflict between them.
The first contribution of this paper is to present the syntax and semantics of the Heraclitus[OO] (abbreviated H2O) DBPL [1].The H2O DBPL generalizes the Heraclitus paradigm [2,3,4] to the object-oriented database model.In particular, the H2O DBPL supports the creation and manipulation of delta values (or more simply, deltas); these are concrete, tabular values that correspond to differences between object-oriented database states.Deltas are first-class citizens in the H2O DBPL, and can be accessed in a hypothetical fashion.Importantly, the delta corresponding to an expression specifying a proposed update allows for efficient repeated access to the proposed change, without re-evaluating each time.Deltas are used in our framework to represent the net effect of proposed updates, and provide the starting point for our framework for detecting potential conflict between them.The H2O DBPL is also of independent interest, because of the broad family of applications for which deltas can be applied, including hypothetical database access, version management, and active databases [4].
The second contribution of this work is the development of a semantically based notion of potential conflict that addresses the issue of detecting conflict between proposed updates, along with a variety of approximations of it.The semantic notion of conflict focuses primarily on (a) the database values read during execution of the expressions specifying the proposed updates, and (b) the specific database modifications that the proposed updates call for.Testing this "pure" notion of potential conflict will typically be quite expensive.To remedy this, we use the deltas of the H2O DBPL to develop a family of conservative approximations of this notion.(Although not considered here, we expect that this framework can be extended to provide automatic and semi-automatic mechanisms for resolving conflicts between proposed updates.) The work presented here is motivated in part by problems arising in the processing of customer change requests at U S WEST, a regional telephone company (see [5] for more on the application of Heraclitus in telecommunications).We believe that the framework will be useful to other applications requiring long transactions, including the broad area of engineering design.
Related Work A variety of systems (see [6,7]) provide mechanisms for the disciplined creation and modification of versions, so that conflicts can be isolated and manually resolved before the base data is corrupted.The H2O DBPL provides language primitives that would support the relatively easy specification of customized version management systems.
Research on managing conflict between deltas has been done in the context of software engineering using "program dependence graphs" [8,9], and in the field of configuration management using "change sets" [10,11].In the first case the analysis of conflict and the algorithms for merging deltas are restricted to the specific application of interest, and in the second case the notion of conflict used is primarily text-based.In contrast, our work develops a general framework for using deltas and detecting potential conflict between them.Speaking intuitively, we exploit the structure provided by a database schema to assist in providing relatively tight approximations of the semantically based notion of conflict.
Our ideas for adding application specific information to refine our approximations of potential conflict between updates is related to research in adding semantic information to concurrency control protocols [12,13].The main distinction is that our conflict analysis is performed on the delta values which represent partial or complete updates, while the semantic concurrency control is based on traditional notions of locking.Also, we provide for the possibility of modifying proposed updates in case of conflict, rather than simply aborting the update.

Organization of the Paper
The remainder of this paper is organized as follows.A motivating example stemming from the U S WEST application is presented in Section 2. In Section 3 we present an overview of the current H2O DBPL prototype.The semantically based definition of potential conflict is given in Section 4, and approximations for this notion based on deltas are given in Section 5. Brief conclusions are presented in Section 6. Due to space limitations, some of the technical details concerning the H2O DBPL are presented in the Appendix (see also [1]).

A Motivating Example
This section introduces a motivating example, which will be used to illustrate various concepts in this paper.The example concerns managing requests from large business customers to change their telephone service.It is a simplified and abstracted version of a real-world example encountered at U S WEST.
The telephone needs of business clients can be very complex, and, as a result, requests to upgrade or modify the telephone service provided to businesses can be intricate.In many cases a business client may wish to explore several alternative ways to upgrade their service before committing to any one of them.For example, if a business is thinking of acquiring voice-mail service, it may wish to contract with the phone company to provide voice-mail, or it may wish to purchase additional lines from the phone company but contract with a third party to provide in-house voice-mail services.After the costs of these alternatives are estimated, the business client may need time (possibly several hours or days) to consider and/or refine them before making a final decision.
A partial, simplified schema of a database that might be used by a telecommunications company for managing customer service is shown in Figure 1.The BusinessCustomer class holds information about business customers that contact the telephone company for service.This class defines attributes such as name, customer id, and billing address.The Location class holds information about customer sites that receive telehone service.The LocalExchange class holds information about the "local exchanges" controlled by the telephone company; these provide switching services at a macro level.The number of local exchanges in an area depends on the size and density of the area.The PBX class holds information about Private Branch Exchanges (PBXs); these are switches that are installed in customer locations.(Speaking loosely, a local exchange considers the first three digits of a seven-digit phone number, and a PBX considers the remaining four digits.)Each PBX connects to at most one local exchange via one or more trunks.The maximum number of trunks is given by attribute maxTrunks.The number of trunks currently assigned is given by attribute noTrunks.Each PBX can also connect to PBXs located at other customer sites.These connections are represented by the set attribute pbxSet.The lines that connect these PBXs are not explicitly represented in this example schema.Figure 2 shows an example of (part of) a state of the database, along with two proposed updates against it.More specifically, the upper left corner of the diagram shows the current state of a subset of the database for a single customer.In the current state, the ACME Brewing Company has two PBXs located at two different sites.Each PBX is connected to its own local exchange by several trunks.In addition, the two PBXs are directly connected to each other.This state is shown textually in Figure 3.The notation for describing an object is the name of the object's class followed by the object's OID and a list of attribute values in parentheses.Attributes are listed in the same order as the attribute names in the class declarations in Figure 1.
The first update in Figure 2 increases by four the number of trunks in the PBX named 'pbx2'.The second update installs a new PBX in a third location, and connects it to both 'pbx1' and 'pbx2', removing the existing connection between 'pbx1' and 'pbx2' (see also Example 4.1).

An Overview of the H2O DBPL
In this section we describe the syntax and semantics used for deltas in the H2O DBPL 1 .A more complete description can be found in [1].
The current H2O DBPL implements a straightforward kind of delta, which we term object-granularity deltas.These deltas can be viewed as a natural generalization of the deltas developed in Heraclitus[Alg,C] [4] for the relational model, with objects replacing tuple values.Section 5 introduces refinements of object-granularity deltas, which are more effective in the context of merging deltas and detecting conflicts between them.

Object-granularity deltas and their operators
We begin our discussion by describing deltas and some algebraic operations on them; these form one part of the semantic domain of H2O.This will prepare us for describing the H2O constructs for creating, accessing and manipulating deltas,  i.e., the syntactic domain of H2O.
In the context of object-granularity deltas, there are three kinds of atomic updates.These are now listed with their intuitive semantics.In the first two cases, v is assumed to have type corresponding to c.In each case, o is called the target of the atomic update.Definition: An object-granularity delta value, or 'delta og ', is a set of atomic updates, such that no oid is the target of two atomic updates.There is also a special delta og denoted fail, which corresponds intuitively to inconsistency.
To illustrate, consider the two updates shown in Figure 2. The corresponding delta og s are: A fundamental algebraic operator in connection with delta og s is apply, which has the effect of applying the changes called for in the delta og to a database state.Since H2O can create and manipulate hypothetical states, the intuitive definitions for the semantics of atomic updates are not sufficiently precise to immediately yield the definition of apply.For example, it is possible that a delta containing an atomic update mod c(o : v) may be applied to a state in which o is not present.Figure 4 in the Appendix defines the semantics of the apply of a delta ∆ on a state DB, by describing the impact of ∆ at an object by object level.(Due to space limitations, we cannot dwell on many of the motivations and subtleties for the definitions presented here.) The computation of delta values corresponding to update expressions is specified by the trace operator.The value of trace captures the sequence of changes to the objects in the database that would occur if the expression were actually executed.The resulting delta value is dependent on the types of the affected objects and the delta form being used.For object-granularity deltas, the trace function can be informally described as follows: (i) the update expression, ,is executed in hypothetical mode, (ii) for each OID o of type mentioned by , atomic commands to insert, delete, or modify the value of o are recorded, and (iii) the net effect of on o is incorporated into the final delta value.The trace operator is used for defining deltafication (see next subsection) and a similarly defined operator, revtrace, is used for defining reverse deltafication.
One operator for combining deltas is smash, denoted using '!'.This is loosely related to the composition operator (;) found in imperative programming languages.The basic property of smash is that for each state DB and each pair ∆ 1 ∆ 2 of deltas, apply(apply(DB ∆ 1 ) ∆ 2 ) apply(DB ∆ 1 !∆ 2 ) (see Figure 5).
The result of smash on the two delta og s given above is: ) (Smash is not commutative for this example, even though it would appear intuitively that the two updates as originally described should commute.The non-commutativity here stems in part from the use of object-granularity deltas; the "attribute-granularity" deltas of Section 5 overcome this problem.)Another binary operator on deltas is merge, denoted using '&'.Intuitively, this operator returns the union of the effects of the two deltas, if there is no conflict between them.The semantics of merge is given in Figure 6 in the Appendix.In general, the merge operator is defined to satisfy the following property:

and no object is deleted by one delta and modified by the other fail otherwise
As illustrated above, the smash on ∆ update1 and ∆ update2 is not commutative, because the two delta og s have conflicting mod atoms targeting object p2.Thus, ∆ update1 & ∆ update2 = fail.(If attribute-granularity deltas were used the merge would be defined.)

Creating, accessing, and manipulating deltas
In this subsection, we briefly present some elements of the syntax and semantics of the H2O DBPL constructs for the creation, access and manipulation of deltas.The H2O DBPL is defined as an extension to the C++ binding of the ODMG standard [15] for object-oriented databases.The syntax of the H2O extensions to the ODMG object manipulation language (OML) for manipulating deltas is given in Figure 7 in the Appendix.Deltas are implemented by the system-defined class delta, and are treated as first-class database objects.As presented in this paper, deltas in the H2O DBPL range over differences between database states.Thus, in defining the semantics of the H2O DBPL we carefully separate 2 the database state from the program state.Speaking loosely, we view the class hierarchy to consist of two separate pieces, one being the database schema and the other being the program schema.(Persistence is orthogonal to the distinction between database schema and program schema.)A database state is a function from classes in the database schema to sets of oids with values (subject to the usual constraints).A program state is a similar function for the program schema, along with a function from all program variables to values (which may be oids from either schema) of appropriate type.We model the full state in a program execution as an ordered pair (P S D B ) with program state P Sand database state DB.
Because the H2O DBPL is an extension of C++, all syntactic objects in the language are expressions.The semantics of these are defined by the expression valuation function, E ] ], which maps expressions from the syntactic domain of the H2O DBPL to the semantic domain of algebraic objects.More precisely, the signature of E ] ] is given by E : Expression !(ps db) !(val (ps db)) which means that an expression yields a function that maps each program state/database state pair into a value and a program state/database state pair.In general, we will be interested in only one of these components, and will use the shorthand notation E val ] ], E ps ] ], and E db ] ] respectively to indicate application of the valuation E ] ] and extraction of the particular component of interest.
One subtlety not immediately apparent from the semantic definitions is the treatment of oids, in particular, the generation of new oids.To simplify our presentation, we model the oid generator as an (infinite) set of unconsumed oids that exists as a persistent object, and view it as part of the program state.Whenever a new oid is needed (either in a regular or a hypothetical expression) an oid is removed from this set.The set of unconsumed oids is kept in the program state, rather than the database state, so that it is not affected by hypothetical operations, and so that uniqueness of oids is guaranteed.
The H2O DBPL provides basic operators for creating, accessing, and combining deltas.We briefly describe three important operators here; these are used in the discussion of potential conflict which follows.Additional operators are described in the Appendix.Deltafication: This provides one way to create deltas.The deltafication of an arbitrary expression (which may have side-effects 3 ) is the expression [< >].Intuitively, evaluation of this expression yields the delta that corresponds to the execution of .The delta ∆ = E val [< >]]](P S D B ) (the delta og associated with [< >] in state (P S D B )) is trace( P S DB) and has the property that apply(DB ∆) = E db ]](P S D B ).This means that the result of applying the delta ∆ to DB is the same as the result of executing the expression on (P S D B ).
Apply: If is a delta expression, then the statement apply has the effect of first evaluating , and then applying it to the database state.Hypothetical Application: Hypothetical access to a delta is obtained using the when operator.Speaking loosely, if is a delta expression and an arbitrary side-effect free expression, then evaluating when in (P S D B ) yields the value that would be obtained if were evaluated against the database state4 apply(DB E val ]](P S D B )), i.e., against the state obtained by applying to the current state.The primary use of when is for hypothetical evaluation of side-effect free expressions.If the expression in when has side effects on the database, these side effects will not be realized outside of the context of the expression.

Pairs of Delta Expressions that are Semantically Conflict Free
This section attempts to lay out a general, semantically-based framework for understanding when proposed updates are conflict free.The following section discusses how delta values can be used to approximate this.The very notion of 'conflict' is quite controversial -exactly what should we take as the definition of conflict between proposed updates?Because the notion of conflict is highly dependent on the underlying application, almost any general definition we choose will be an approximation of the "true" notion of conflict.In this section we propose a formal, semantically-based notion of "conflict free" that focuses on the actual code used to define the proposed updates, and which is independent of particular application domains.More specifically, this notion examines the values read by the expressions specifying proposed updates and the values actually changed by them.Although this notion has short-comings, it provides a starting point for discussion.
In this section and the next, we focus on proposed updates specified using delta expressions of the form = [< >]; these correspond to the hypothetical execution of a proposed update specified by the expression .At the end of the section we briefly consider "interactive delta expressions", which might model more closely the change requests arising in the telephone company example.We have not yet investigated the notion of conflict free for delta expressions built using variables, the binary operators, or reverse deltafication.
Suppose now that 1 = [< 1 >] and 2 = [< 2 >] are delta expressions, i.e., expressions that describe proposed updates to a (partial) database state.Both 1 and 2 might involve multiple reads of the database state, in addition to multiple writes (and modifies) against it.
Our main focus is on how 1 and 2 affect the database state.For this reason we generally assume that the computations represented by 1 and 2 are not dependent on program state variables (i.e., program state variables are just scratch-pad-like objects).Thus, in this section and the next we typically write E val 1 ]](DB) rather than the technically more correct E val 1 ]](P S D B ).
A preliminary notion is that of "read interference".Speaking informally, 2 = [< 2 >] "interferes" with 1 = [< 1 >] if the sequence of values read by 1 when executed in DB is different 5 from the sequence of values read by 1 when executed in the result of applying 2 to DB.But what is meant by the notion of "values read"?We now define two "modes" for reading: "answer-based read monitoring" and "envelope-based read monitoring".These modes can be viewed as the ends of a spectrum of possibilities.
Suppose first that there is a strict separation between database queries, database updates, and other processing, as for example occurs in C with embedded SQL.In this case the "sequence of values read" by a delta expression = [< >] can refer to 6 the sequence of answers to database queries executed.A separation between database accesses and other processing might also be enforced when using, e.g., CO 2 or some other commercial OODB language.We shall call this answer-based read monitoring.
In many cases a discipline of separating database access from other computations may not be followed.In this case a more crude notion of "values read" might be used.A very basic approach is to define the "sequence of values read" to be the sequence of all objects explicitly retrieved along with their full values.Speaking intuitively, this sequence corresponds to an "envelope" around the set of objects and values that actually affect the evaluation of the delta expression.We shall call this (object-granularity) envelope-based read monitoring.
Before continuing we briefly consider the impact of constraints.In this paper we consider any automatic constraint checking and/or repair mechanisms in use to be an implicit part of the expression .Thus, any data read as a part of automatic constraint checking will be included in the "values read", and any database modifications automatically performed to repair constraints will be included as updates called for by .The issue of constraints is a topic for further research.
We now have: When testing whether 2 interferes with 1 in DB, we expect that E val 2 ]](DB) will be evaluated to yield the delta value ∆ 2 .If d is a delta variable holding ∆ 2 , then testing for interference can be done by comparing the execution of 1 and the execution of 1 when d.
Our semantically based definition of conflict free is: Two delta expressions have semantic potential conflict (under a given mode of read monitoring) if they are not semantically conflict free.
Speaking loosely, the first two conditions focus more on whether there is conflict between 1 and 2 in terms of what they access from the database.The last two conditions focus more on conflict in terms of how they change the database.The primary motivation for the fourth condition is the intuition that there is a conflict between attempting to delete an object and attempting to modify it.(See also the semantics of merge in Figure 6.)(a) For this case, assume that the code for 1 selects all PBX objects having id equal to 'pbx2' and increases the number of trunks by four.For simplicity, we will ignore the constraint noTrunks maxTrunks in this example.Expressed in pidgin OQL and OML, the code for 1 is: change_set_a = select y from y in PBX where y.id = 'pbx2'; foreach y in change_set_a { y.noTrunks = y.noTrunks+ 4; }; Assume further that the code for 2 installs a new PBX in location l3 and connects it to both 'pbx1' and 'pbx2', removing the existing connection between 'pbx1' and 'pbx2'.The code for 2 (i) poses two queries, one for PBXs with attribute id = 'pbx1' and one for PBXs with attribute id = 'pbx2'; (ii) inserts a new PBX object; and (iii) updates all pbxSet attributes to reflect the new connections.
In this case, under answer-based read monitoring 1 does not interfere with 2 nor visa-versa.(This is true in part because all of the queries in 1 and 2 return only the oids of various objects, but none of their attribute values.)Under envelope-based read monitoring both interfere with the other, because both expressions read the object p2, and both modify values of attributes of p2.In summary, 1 and 2 are semantically conflict-free under answer-based read monitoring, but have potential semantic conflict under envelope-based read monitoring.(b) For this case, suppose that 1 is: change_set_b = select y from y in PBX, x in PBX where x.id = 'pbx1' and y.le != NULL and y in x.pbxset and x in y.pbxset; foreach y in change_set_b { y.noTrunks = y.noTrunks+ 4; }; Intuitively, change set b holds all PBX objects that are directly connected to 'pbx1' and also connected to a local exchange.Let 2 be as before.In this case, under answer-based read monitoring 1 does not interfere with 2 , but 2 does interfere with 1 .Also, in this case the executions of 1 and 2 do not commute.In sum, 1 and 2 have potential semantic conflict under both modes of read monitoring.(c) Suppose now that the code for 1 computes both change set a and change set b as in the above cases, but then uses change set a when increasing the number of trunks.In this case the database access to compute change set b is essentially ignored in the code of 1 , but answer-based read monitoring is unable to discern that.Now, 1 and 2 have potential semantic conflict under both modes of read monitoring, even though 1 and 2 commute.

2
Suppose now that delta expressions 1 = [< 1 >] and 2 = [< 2 >] are semantically conflict free.This means that 1 and 2 can be applied to the database state in either order to yield the same result, and that they do not conflict with regards to deleting vs. modifying the same object.At an intuitive level, application of 1 and 2 in either order yields a result that captures the intention of both.
Suppose now that we do not want to apply these, but rather, we want to create a delta expression that combines the intention of both.If they are semantically conflict-free, both of the delta expressions [< 1 ; 2 >] and [< 2 ; 1 >] yield the desired "merge" of the two delta expressions.
We noted earlier that if a notion of delta value is available, then testing for interference between delta expressions can be performed by using delta values and hypothetical evaluation under when.If the algebraic merge operator is defined appropriately for delta values, this can be extended to form a sufficient condition for semantic conflict free.For example (proof omitted): 1 does not interfere with 2 in DB 2 does not interfere with 1 in DB ) ) 1 and 2 are semantically conflict free in DB (This result remains true for the other notions of delta value and merge presented in this paper.) The notion of semantic potential conflict can be generalized to apply to sets of delta expressions.
In some applications a proposed update might be the result of an extended interaction between human and computer, rather than the result of evaluating an expression of the form [< >].We have developed a notion of interactive delta expression, which is a sequence of queries, actions, and pauses (for human reflection).There are natural generalizations to interactive delta expressions of the notion of semantically conflict free, and of the notions developed in Section 5.

Customizing Delta Values
In the previous section we introduced the notions of semantically conflict free and semantic potential conflict.We expect that testing for these properties will typically be prohibitively expensive.This leads to the development of conservative, syntactically-based approximations of conflict free which are much less expensive to test.There will be two basic dimensions in the creation of these approximations: (a) different notions of delta values developed for different classes of objects, and (b) different approaches to approximating the "read set" of a delta expression.The primary focus in this section is on issue (a).
We first show how the object-granularity delta values of Section 3 can be used to approximate the notion of semantically conflict free.We then develop two refinements of delta values that provide closer approximations of semantically conflict free.The first refinement is quite general and the other is much more application specific.We are developing a framework [16] in which that different kinds of delta values can be used for different classes in a single object-oriented database schema.

Object-granularity conflict free
The driving idea of the notion of object-granularity conflict free is to use object-granularity deltas when approximating conditions (iii) and (iv) in the definition of semantically conflict free.In this subsection we develop this notion in the context of answer-based read monitoring, and briefly indicate how the notion is defined for envelope-based read monitoring.
In order to test for possible conflict, we extend the notion of delta to include information about the set of values read.In the context of answer-based read monitoring, we shall use the following approach.Definition: A query-extended delta og (value) is a pair (Q ∆) where (i) Q is a sequence of7 closures of queries, and (ii) ∆ is a delta og as in Section 3.
Intuitively, Q corresponds to the sequence of database queries asked by a delta expression , and ∆ captures the specific modifications called for by .
be two query-extended delta values.Then D 1 and D 2 are (object-granularity) conflict free (under answer-based read monitoring) in state DB if (abusing notation somewhat):8 , Otherwise they have object-granularity potential conflict in DB (under answer-based read monitoring).
Speaking intuitively, condition (iii) here captures the spirit of both conditions (iii) and (iv) of the definition of semantic conflict free.
Example 5.1: Recall Example 4.1, and consider case (a) of that example.Let D i = ( Q i ∆ i ) be the query-extended delta og corresponding to i for i = 1 2. Then conditions (i) and (ii) in the definition of object-granularity potential conflict between D 1 and D 2 are not violated.However, ∆ 1 &∆ 2 = fail, because both deltas modify the value of p2.
Thus, condition (iii) is violated.(In Example 5.3 we shall see that if attribute-granularity deltas are used, then condition (iii) is not violated.)Consider now case (b) of Example 4.1.In that case condition (i) of object-granularity conflict free between D 1 and D 2 is violated.This is also true for case (c). 2 It is easily verified that object-granularity conflict free under answer-based read monitoring is a conservative approximation of semantic conflict free: Proposition 5.2: Assume object-granularity delta values.Let DB be a state, and 1 = [< 1 >] and 2 = [< 2 >] be two delta expressions.Let D i = ( Q i ∆ i ) be the query-extended delta og corresponding to i in DB for i = 1 2.Then, relative to DB, (Q 1 ∆ 1 ) and (Q 2 ∆ 2 ) are object-granularity conflict free ) 1 and 2 are semantically conflict free.
Analogous results can be developed for envelope-based read monitoring.Briefly, an (object-granularity) envelopeextended delta og value is a pair (R ∆) where R is a set of oids along with their values, and ∆ is a delta og value.Given a delta expression and state DB, the corresponding envelope-extended delta og value will be (R E val ]](DB)), where R is the set of all database oids and their values that are accessed and/or hypothetically changed in the evaluation .

Attribute-granularity delta values and conflict
A straightforward refinement of object-granularity deltas is to redefine atomic modifies so that they focus on the modification of a single attribute value, rather than the full value of an object.Delta values constructed in this way are called attribute-granularity delta values, denoted delta ag .The notions of apply, smash and merge are defined for delta ag s in the natural manner, as are attribute-granularity conflict free and potential conflict.Also, the notion of envelope-based read monitoring can be refined to focus on individual attribute values rather than full object values.The analog of Proposition 5.2 is easily demonstrated.

> = > :
Recall Example 4.1(a), and let D i = ( Q i ∆ updatei ) be the query-extended delta ag corresponding to i (i = 1 2).Then D 1 and D 2 are attribute-granularity conflict free. 2 5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 The approach of attribute-granularity delta values can be refined further, by going deeper into the structure of individual attributes.For example, the pbxSet attribute is set-valued.Modifications to the value of this attribute might be represented as a family of individual inserts and deletes to the set.Under this approach, the first modify of ∆ 0 update2 would be represented as mod PBX(p1 : pbxSet : ins p3 del p1): Another direction is possible if a family of operators are defined on the type of some attribute.For example, addition and subtraction are defined on the type non-negative integer, i.e., the type of noTrunks.We might permit atomic delta values of the form mod PBX(p1 : noTrunks : +4): This notion of defining specialized delta operators for specific data types has been formalized as delta forms and delta form templates have been defined for standard complex value types [16].In the next subsection, we illustrate by presenting one specific example of a specialized delta form.

Deltas for objects consisting of undifferentiated sets
We now present a specialized kind of delta value that is useful in contexts where there are undifferentiated sets of objects.Such undifferentiated sets arise in some applications at U S WEST.More generally, this discussion illustrates how delta values can be customized for a particular data type.We present this specialized delta in terms of a concrete example; we have also developed a formal specification.
The class PBX presented in Figure 1 in Section 2 is simplified in a variety of ways.In reality, a record must be kept, for each PBX, of which individual trunks are connected to which individual ports at the local exchange.Thus, a slightly more realistic interface for PBX is given by: interface PBX' { attribute string id; attribute BusinessCustomer customer; attribute Location loc; attribute LocalExchange le; attribute int maxTrunks; attribute Set<Tuple<trunk_id,le_line_id>> trunk_assignment; attribute Set<PBX> pbxSet; }; Here the trunk assignment attribute holds a set of ordered pairs9 (t l), where t is a trunk id for the PBX and l is a line id for the local exchange that the PBX is connected to, and this forms a 1-1 correspondence.To simplify this discussion, we shall omit the noTrunks attribute.Using the class PBX', the object corresponding to p1 in the running example might be PBX'(p1: 'pbx1', b1, l1, e1, 64, { <t1,lep25>, <t2,lep26>, <t3,lep27> }, {}), indicating that the trunk t1 is attached to the local exchange port lep25, etc.
Consider now two proposed updates 1 and 2 , that both assign an additional trunk line of 'pbx1'.Under a straightforward choice of delta ag s that permit explicit inserts and deletes to set-valued attributes, the following might be associated with these two updates: ∆ 1 = fmod PBX 0 (p1 : trunk assignment : ins < t4 l e p 88 >)g ∆ 2 = fmod PBX 0 (p1 : trunk assignment : ins < t4 l e p 253 >)g Speaking intuitively, when creating each delta the system apparently chose the "next available" trunk id from 'pbx1'.This has the unfortunate side effect that ∆ 1 and ∆ 2 have semantic conflict, since the requirement that there be a one-to-one correspondence in trunk assignment will be violated if both delta ag s are applied.However, the two delta expressions are compatible, because the total number of trunks used by the original state and the two deltas is less than 64.
Our solution to this problem is based on the fact that the trunk id's should be viewed as undifferentiated.We suppose that a new class virtual trunk id is created, with an infinite number of elements.If creating a delta value for the class PBX' for which an unused trunk id is needed, then we use an unconsumed element of virtual trunk id in its place.Thus, the two delta expressions above would now be evaluated into: ∆ 0 1 = fmod P BX 0 (p1 : trunk assignment : ins < v t1 l e p 88 >)g ∆ 0 2 = fmod P BX 0 (p1 : trunk assignment : ins < v t2 l e p 253 >)g (The exchange line id's might also be undifferentiated; we ignore that possibility here to simplify the discussion.)Briefly, a delta ∆ using such undifferentiated values is consistent relative to a database state DB for a given PBX p if the total number of trunks already in use for p plus the number of virtual trunk id's for p occurring in ∆ does not exceed the value of p.maxTrunks.The semantics for applying such a delta involves a non-deterministic assignment of actual trunk id's to virtual trunk id's.The smash of two such delta values is defined in the natural fashion, but yields inconsistency (fail) if the total number of trunk id's used in the smash exceeds the bound given by maxTrunks.Analogous comments apply to merge.Importantly, we permit the use of virtual trunk id's in the same places as trunk id's -this permits the construction of complex deltas with attributes of other objects referring to newly assigned trunk lines.

Conclusions
This paper has two foci: (a) introducing the syntax and semantics for deltas in the H2O DBPL, and (b) laying some of the groundwork for using deltas to help detect potential conflict between proposed database updates.An example arising in a regional telephone company was used to motivate and illustrate the development.
This paper raises a host of issues.In Section 5 we described two refinements of object-granularity deltas, and indicated how they provided better approximations of the notion of semantic conflict free.We are also developing customized notions of delta that are appropriate for trees and graphs.An important open problem is to develop a framework for specifying customized delta values in a uniform fashion, that can be compiled into implementations for them (see [16] for initial results in this direction).
Another issue concerns constraints.Suppose that an active database rulebase is used to monitor constraint violations and to repair them.It might be appropriate for the delta associated with the expression = [< >] to include the impact of any constraint repairs that would have occurred were executed.Thus, our prototype implementation of the H2O DBPL would need to be extended to incorporate hypothetical rule firing.The merge and smash operators on delta values would also need to be generalized.(Some difficulties would arise if the rule base is not "semantically consistent" in the sense of [17], i.e., if the rule base yields different results on update requests that are semantically equivalent but syntactically different.) In this paper we focused on detecting conflict between proposed updates.A natural direction is to develop mechanisms that would help to resolve conflicts that are detected.Active database technology looks promising here.Unlike previous applications of active databases, in this context the rules should be able to explicitly refer to deltas as independent objects.
Although not discussed in this paper, we have found that using an equivalent but different database schema can impact the various approximations of semantic conflict free.The presence of derived data can also impact the various approximations.Thus, the decision to use (a particular variety of) deltas to help detect conflicting updates may have an impact on the schema design process.This appendix gives some additional details on the H2O DBPL; see [1] for a full specification.

On Detecting Conflict Between
The specification for the apply, smash and merge operations on object-granularity deltas are given in Figures 4, 510 and 6. 11The syntax of the H2O extensions to the ODMG object manipulation language (OML) is presented in the BNF grammar in Figure 7.The productions h2o stmt, when exp and delta exp define new H2O constructs.The remaining productions show how these constructs are integrated with C++ and come from the specification given in Appendix A of [18].
The semantics of the H2O DBPL syntactic constructs is given in Figure 8.The semantics are defined by the expression valuation function, E ] ], which maps expressions from the syntactic domain of the H2O DBPL to the semantic domain of algebraic objects.As noted in Section 3, states are viewed to be pairs (P S D B ) where P S denotes the program state and DB denotes the database state.Since the H2O DBPL is based on C++, we follow the convention that expressions can have side-effects on the state.Thus, under E each expression yields a mapping from a state to a value (the result of the expression) and a new state.Similarly, statements are treated as expressions that yield the null value.In Section 3 we described the deltafication, apply, and hypothetical access constructs of the H2O DBPL.The other major constructs for creating, accessing and combining deltas are now described.
Reverse Deltafication: The reverse deltafication of a statement (which may have side-effects) is the expression [> <].Intuitively, the semantics is to execute on the current state, and to return a delta that can "undo" the effect of .
Accessing deltas: As described in Section 3, the H2O DBPL provides two ways to access a delta, using apply and when.

Combining delta expressions:
The H2O DBPL provides keywords corresponding to the binary operators smash and merge.It also provides a third binary operator called "compose".(where P S 0 = E ps 1 ]](P S D B )).Note here that 2 is evaluated in the initial database state DB, rather than in a context with database state apply(DB E val 1 ]](P S D B )).
merge: The keyword merge is analogous to smash.
compose: This operator does not have an analog in the algebra of deltas.The expression 1 compose 2 yields a delta that corresponds to the result of evaluating 1 and then applying it, followed by evaluating 2 and then applying it.
Intuitively, we would expect evaluation of a delta expression to have no side effects on the state.Consider for example a delta expression = [< >].As indicated by the semantics of Figure 8, evaluation of leaves the database state unchanged.However, the program state may change, both because (i) new oids might be used, or because (ii) involves explicit modification to program variables.The latter case reflects a design decision motivated primarily by pragmatic considerations.
Some delta expressions can have side-effects on the database.One example is reverse deltafication: [> <] yields a delta value and also executes against the current state.Other examples arise as the result of the C++ language.
For example, if x holds an object o 17 whose value has type integer, then the right-hand side of the H2O expression d = [< >], x = 2; yields a delta, but has the effect of changing the value of o 17 to 2. Although we discourage this kind of expression, we do not prohibit it.For this reason, when defining the semantics of 1 smash 2 we allow the possibility that evaluating 1 might have side-effects on the database state.Analogous remarks apply to the semantics of merge, compose, and when.

Figure 1 :
Figure 1: Part of schema for telecommunications example.
ins c(o : v) -Insert a new object of class c with oid o and value v. mod c(o : v) -Modify the object of class c with oid o to have the new value v. del c(o) -Delete the object of class c with oid o.
and let DB be a database state.Then 2 (read) interferes with 1 in DB under answer-based [envelope-based] read monitoring if the sequence of answers to queries asked [objects accessed and their values] by 1 when executed in DB is different from the sequence of answers to queries asked [objects accessed and their values] by 1 when executed in E db 2 ]](DB).

Example 4 . 1 :
We now present three examples that illustrate these notions, using Figure2of Section 2.

Proposition 4 . 2 :
Let DB be a state, 1 = [< 1 >], and 2 = [< 2 >].Assume the use of delta og values and the merge operator of Section 3. Suppose that ∆ i = E val i ]](DB) for i = 1 2.Then, using either mode of read 5th International Workshop on Database Programming Languages, Gubbio, Italy, 1995 On Detecting Conflict Between Proposed Updates monitoring:

Figure 4 :Figure 5 :
Figure 4: Semantics of the apply operator on individual oid o

occurrence of o in ∆ 1 occurrence of o in ∆ 2 absent 6 = v 2 Figure 6 :
Figure 6: Semantics of the merge operator (&) on individual oid o

Figure 8 :
Figure 8: Portion of H2O DBPL semantics To are semantically conflict free in state DB, under answer-based [envelope-based] read monitoring if (i) 2 does not interfere with 1 in DB under answer-based [envelope-based] read monitoring, (ii) 1 does not interfere with 2 in DB under answer-based [envelope-based] read monitoring, (iii) 1 and 2 commute on DB, i.e., executing 1 ; 2 and executing 2 ; 1 on DB yield the same result, and (iv) there is no oid o such that 1 has the effect in DB of deleting o and 2 has the effect in DB of modifying the value of o (or visa versa).