WEIKUM, G. Principles and realization strategies of multilevel transaction management. ACM Transaction on Database System 16, 1 (1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....or inferred at compile time. It may also be deduced at run time, according to the user profile (e.g. access authorization) or by analyzing database logs. The same policy can be applied when T1 and T2 are not data independent but are commutative, following the idea of multi level transactions [11]: propagating T1 to N2 after the execution of T2 leads to the same database state as propagating T2 to N2 after the execution of T1. However, commutativity between non data independent transactions should be explicitly stated, since it seems difficult to infer it from both static and dynamic ....

WEIKUM, G. Principles and realization strategies of multilevel transaction management. ACM Transaction on Database System 16, 1 (1991.

....is an extension of OQL. We then identify different approaches to address consistency For semistructured data model. First, we examine different consistency models to find out which existing models may be appropriate. We define our consistency model in the frame of multi level transaction model [16]. The consistency is ensured via a notion of serializability, which is based on commutativity relationships between operations of different transactions. We then identify basic operations on semi structured data which may be used as a basis for data manipulation algebra, and investigate ....

....based on traditional read write paradigm are too restric tive in heterogeneous distributed environment, especially when primary data sources are not accessible directly due to presence of wrappers and mediators. One of promising approaches to consistency is based on multi level transaction model [8, 16]. In contrast with tra ditional transactions, which are built as sequences of read 58 or write operations, multilevel transactions axe constructed as a complex control structure. Each level of a transaction is considered as a sequence of abstract operations, each of which is considered as ....

Gerhard Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactionson Database Systems, 16(1):132-180, March 1991. 63

....with transactions of each semantic type. The compatibility set of an atomic step determines the atomic steps of other transactions that can be interleaved with it. A similar approach was proposed by Lynch [26] where the interleaving set of a transaction is hierarchically structured. Weikum [39, 40] investigates a special case of hierarchically structured transactions in which the levels for each transaction are fixed. He then proposes the use of semantics of operations at different levels to increase concurrency in the system. The notion of interleaving sets and breakpoints was extended by ....

WEIKUM, G. Principles and realization strategies of multilevel transaction management. ACM Trans. Database Syst. 16, i (Mar. 1991), 132 180.

....object store, and some simple experimental results. The techniques we propose to adopt seem to be well suited for the high levels of a complex system, and they appear to be less adequate for the low levels. We have the impression that the complementary situation holds for multi level transaction [Weikum 91] and in the next future we will investigate the possibility of combining in a single framework the two approaches. Another future work will be about a closer examination of the measurements provided from the proposed techniques. 6. ....

Weikum G., "Principles and Realization Strategies of Multilevel Transaction Management", ACM Transactions on Database Systems, Vol. 16, No. 1, pp. 132-180.

....aspects have to be re investigated for the object oriented paradigm. The work done in [35] a unified model for reasoning about both correctness criteria, is also of interest for the object oriented case. Another promising approach is to examine the relation between multilevel transactions [39] and repeatedly applied refinement steps during the refinement process. Work in this direction has been done in [11] Acknowledgements The formalization of a well defined denotational semantics of object specifications in terms of event structures contributed by Hans Dieter Ehrich, Braunschweig, ....

G. Weikum. Principles and Realization Strategies of Multilevel Transaction Management. ACM Trans. on Database Systems, 16(1):132--180, March 1991.

....by implementing the protocol directly inside the transaction manager of the database. However, this approach most of the times is not feasible. In here, the protocol resides outside the database in a middleware layer. Our approach has been to follow ideas from multilevel scheduling [Wei91] and composite systems [PA00] where an additional transactional scheduling layer is used to improve concurrency and to introduce higher order semantics as part of the scheduling procedures. The implementation described above combines, at the middleware layer, the replication protocol and a ....

G. Weikum. Principles and Realization Strategies of Multi-level Transaction Management. ACM Transactions on Database Systems, 16(1):132180, March 1991. 25

....early release of locks at lower levels of control; however, they rely on compensation operations for subtransactions to be applied in the case of rollback recovery. A detailed description of all aspects of multi level transaction management including a discussion of performance issues is given in [Weikum91]. Here, we don t want to consider this kind of multi level structure and concurrency control for centralized DBMS operations. Due to the salient properties supported by nested transactions, many researchers have focussed attention on the design and implementation of them in distributed systems. ....

Weikum, G.: Principles and Realization Strategies of Multilevel Transaction Management, ACM TODS, Vol. 16, No. 1, 1991.

.... database systems [BGMS92, ZE93, BS88, GRS91, GRS94] We utilize the ticket method which guarantees global serializability by the explicit introduction of local con icts between global transactions [GRS94] Other solutions for nested global transactions are multilevel transaction management [Wei91] which requires the speci cation of con ict semantics on the global layer, the DOM transaction model [BOH 92] and the Interbase transaction model [ELLR90] All these approaches are not applicable for ODMGcompliant MDBS because they require extensions of ODL and the ODMG transaction model to ....

G. Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems, 16(1):132--180, 1991.

....on a PC cluster. They conclude that PC clusters are well suited when correctness is not important. Correctness corresponds to the notion of serializability from transaction theory [5] An efficient way to implement correctness in combination with high parallelism are multi level transactions [1, 24, 25]. 2] as well as [13, 17] describe document services and architectures of document engines that are based on multi level transactions. 2] does not provide an evaluation, and the article does not address scalability issues. This in turn is one of our main contributions. Another approach is to ....

....Document Service Transactions This subsection describes the concurrency control mechanisms of our system. With document engines, global transactions consist of one or more document service requests. The system cannot execute transactions concurrently in an arbitrary manner because of conflicts [25]. For our document engine, an insertion service s 1 and a retrieval service s 2 conflict if and only if the document of s 1 qualifies for the query of s 2 and both services belong to different transactions. Serializability of a schedule yields correct executions. We have applied a semantic ....

G. Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems, 16(1):132--180, 1991.

.... A layered transaction model is a mechanism for distinguishing between the transactional semantics to be applied to top level data (e.g. objects) and those applied to low level data (underlying data which is not directly useraccessible, e.g. indices and object graph meta data) Moss et al. 1986; Weikum 1991] If such a distinction can be made, isolation between user level transactions can be safely maintained with respect to top level data, while allowing a measure of concurrent access to low level data. This avoids the problem of transactions that are otherwise mutually exclusive being serialized ....

WEIKUM, G. 1991. Principles and realization strategies of multilevel transaction management. TODS 16, 1, 132--180.

....be tried to be found from o j01 if v aborts. By backing to some o k (k j) another path for o k may be tried to be 7 found. o tries to find alternate paths for o j01 It can not be seen from the higher level of o, i.e. the movement on o is atomic. Thus, the vehicle transaction v on o is nested [10, 11, 16]. 4.2 Releasing schemes After leaving o, v can release o. If v is a strict two phase locked (2PL) 3] transaction, v does not release objects until v arrives at the destination. This means that objects which v has passed through already cannot be used by another vehicle. It decreases the ....

Weikum, G., "Principles and Realization Strategies of Multilevel Transaction Management," ACM TODS , Vol. 16, No. 1, 1991, pp.132-180. 11

....P o , a thread of op is created and is computed in o, and sends back a response message with the result of op. During the computation of op, op may invoke operations on other objects, i.e. operations are nested. The conflicting relation among the operations is defined based on the semantics of o [7, 11, 21]. Unless two operations op 1 and op 2 conflict, the state of o obtained by applying op 1 and op 2 in any order is the same. In order to tolerate the fault of each object o, o takes a checkpoint where the state of o is saved in the stable storage log. If o is faulty, o is rolled back to the ....

....denotes a state obtained by applying op to s. For every pair of operations op 1 and op 2 , op 1 ffiop 2 means that op 2 is applied after op 1 . Definition] Operations op 1 and op 2 of an object o are compatible if and only if (iff) op 1 ffiop 2 (s) op 2 ffiop 1 (s) for every state s of o [7, 11, 21]. 2 op 1 and op 2 conflict [1] iff they are not compatible, i.e. op 1 ffiop 2 (s) 6= s for some state s of o. The conflicting relation among the operations is assumed to be specified in the definition of o. op 1 and op 2 are mutually exclusive in o iff op 1 and op 2 cannot be simultaneously ....

Weikum, G., "Principles and Realization Strategies of Multilevel Transaction Management," ACM TODS , Vol. 16, No. 1, pp.132-180, 1991.

....that the RC method handles the conflicts between physical operations within a transaction. In both cases, the RC method and concurrency control are scheduling operations at different levels. Some RC methods integrate these scheduling decisions in a way analogous to multi level concurrency control [45]. They are described in Section 4. Traditionally, distributed concurrency control must maintain serializability. Consequently, RC methods wishing to allow consistency weaker than serializability cannot be easily integrated. ESR (Section 4.2.1) eventual consistency [41] and other proposals ....

G. Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems, 16(1):132--180, March 1991.

....system, hence the denomination flat . 2. Multilevel transactions. Such transactions occur in systems that offer to the programs the same type of operations to start and to terminate a transaction as before, but there exists two or more levels of transactions and database access operations [Wei91] One operation that appears atomic at one level is implemented as a transaction, with operations in the immediately next lower level. 3. Nested transactions. In this case the system offers to the programming system an operation to start a transaction, and after this, the program can arbitrarily ....

....of operations that conflict. The fundamental theorem of the theory relates the conflict serializability of an execution with the absence of cycles in its corresponding graph [BHG87] Most of the results of the classical theory of database are also available in terms of multilevel transactions [Wei91] 5 Our first contribution presented in this dissertation is related to extending the results of conflict serializability of the classical theory from flat to nested transactions. We have developed the definitions and proofs for a theorem applicable to nested transactions that emulates the ....

[Article contains additional citation context not shown here]

G. Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactions On Database Systems, 16(1):132--180, 1991.

....TCP IP, SNA, X.25) information resources (e.g commercial relational and object oriented DBMSs) and application services (e.g. X.500, X.400) have been built. 16 6 Summary Hierarchical structures of extended transaction models such as nested transactions [39] and multi level transactions [50] are often too rigid for workflow applications. A basic problem with the development of workflow management systems based on a particular transaction model is that a predefined set of properties provided by the model may or may not be required by the semantics of a workflow. For example, intertask ....

G. Weikum. Principles and Realization Strategies of Multilevel Transaction Management. ACM TODS, 16(1), March 1991.

....be done automatically, and hence future work will be to investigate, what concepts and protocols are needed to support compensation on the system level. We are confident that we can learn from the research conducted in the field of transaction models (e.g. Sagas [GMS87] open nested transaction [Wei91][WS91] etc. ....

Weikum, G.: "Principles and realization strategies of multi-level transaction management". ACM Transactions on Database Systems, 16(1): pp. 132-180, March 1991

.... update propagation strategies, recovery algorithms can be classified with regard to whether any undo steps and or redo steps have to be applied during a warmstart [BHG87] In addition to these classical paradigms, recovery for multi level transactions has to satisfy the following requirements [Wei87a, BSW88]: 1) High level undo: Undo steps for an incomplete n level transaction must be based on inverse L(n 1) actions, so as to preserve (complete multi level) serializability. This means that high level (subtrans) actions must be compensated rather than backed out. 2) High level action ....

....even for single level transactions. Multi level recovery principles are discussed in [MGG86] Wei87b] and [We89] but these papers concentrate on transaction aborts. To our knowledge, the only work that has addressed crash recovery principles for multi level transactions is reported in [BSW88, DeL87, Wei87a]. Our contribution here is new in that it shows how the results of these papers can be used for systematically developing an efficient multi level recovery algorithm. Multi level crash recovery algorithms have been implemented in the commercial database systems SQL DS (this is basically System R ....

Weikum, G., Principles and Realization Strategies of Multi--Level Transaction Management, Technical Report, University of Darmstadt, 1987

No context found.

WEIKUM, G. Principles and realization strategies of multilevel transaction management. ACM Transaction on Database System 16, 1 (1991.

No context found.

G. Weikum. Principles and Realization Strategies of Multilevel Transaction Management. ACM Transactions on Database Systems (TODS), 16(1), 1991.

No context found.

. Weikum, G.: Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems, Vol.16, No.1, pages 132-180, March 1991

No context found.

Weikum, G. Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems 16(1) (March 1991), 132-180.

No context found.

G. Weikum. Principles and Realization Strategies of Multilevel Transaction Management. ACM Transactions on Database Systems (TODS), 16(1), 1991.

No context found.

G. Weikum. Principles and Realization Strategies of Multilevel Transaction Management. ACM Transactions on Database Systems (TODS), 16(1), 1991.

No context found.

G. Weikum, "Principles and Realization Strategies of Multilevel Transaction Management", ACM Transactions of Database Systems, Vol 16, No 1, pp 132-180, 1991.

No context found.

G. Weikum, Principles and realization strategies of multi-level transaction management, ACM Trans. Database Syst. 16(1) (1991) 132-180.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC