A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for InterBase. In Proc. of the Int. Conference on Very Large Databases, Brisbane, Australia, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....among them. # Lock mechanism reduces the throughput or concurrency. The longer the duration, the larger the reduction. To address the above problems, several extended transaction models [8,11] have been proposed, including Sagas [10] longrunning activities [5,6] ASSET [3] multi databases [9,16] and so on. Usually, they are called advanced transaction models (ATM) to distinguish from the traditional one. Many of these models are developed from a database point of view and are too databasecentric to provide adequate flexibility. In this paper, a transaction model CovaTM is proposed to ....

....hand, compensating a sub transaction can be very expensive and sometimes it is unnecessary. An example can be found in [7] and other problems related to Saga can be found in [13] Nevertheless, the idea has been implemented in a workflow management system [1] Flexible Transactions This model [9] is suitable for multidatabase environment where each local database acts independently from others. In such environment, it is not possible to enforce the commit semantics of a global transaction [16] A flexible transaction uses functionally equivalent sub transactions as its alternative ....

A. K. Elmagarmid, Y. Leu, W. Litwin and M. Rusinkiewiczt, A Multidatabase Transaction Model for InterBase, in proceedings of VLDB'90 (Brisbane, Australia 1990), 507518

....the task coordination requirements. In general, the task can either be statically or dynamically defined throughout execution. Statically: The tasks and dependencies among them are defined before execution of the workflow starts. Some of the relaxed transactions (e.g. Flexible Transaction [14] use this approach) A generalization of this strategy is to have a precondition for execution of each task in the workflow, so that all possible tasks and their dependencies are known in advance, but only those tasks whose preconditions are satisfied are executed. Such an approach was reported in ....

....steps and how forward recovery can be handled by making input and output steps persistent. APRICOTS [25] is a prototype implementation of the ConTract model. It does not allow for dynamic workflow and does not support the flexible integration of heterogeneous task structures. The Flex model [9, 10, 14] is an early model which relaxes the atomicity and isolation properties of its transactions. A verity of dependencies are possible between sub transactions. The InterBase project at Purdue [9] for example, is based on the Flex model and enables the execution of distributed programs on ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. Multidatabase Transaction Model for InterBase. In Proceedings of the 16th VLDB Conference, 1990.

....Similarly, in the NT PV model [9] and the ConTract model [14] invariants have been used to allow more concurrency. To guarantee the atomicity of long lived transactions, compensating transactions [6] have been widely used in many advanced transaction models, such as Sagas [3] ConTract, Flex [2], Multi level Transactions and Open nested Transactions. For a transaction T , a compensating transaction C is a transaction that can semantically undo the effects of T after T has been committed. For example, the compensation of a withdrawal can be a deposit. To deal with the problem of ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for interbase. In Proceedings of the 16th VLDB Conference, Brisbane, Australia, August 1990.

....exceptions and error conditions beforehand. A workflow management system must provide means to cope with such situations. Similar ideas are found in advanced transaction models [6] such as Sagas [8] for backward recovery, i.e. how to undo the effects of certain operations, or in Flex transactions [5, 21, 28] for forward recovery, i.e. how to select different paths of execution. However, in workflow systems there are certain errors that may force the user to abort the execution of a process instance, and therefore to lose work that has to be performed again when the process is restarted. Forward ....

A.K. Elmagarmid, Y. Leu, W. Litwin, M.E. Rusinkiewicz, A Multidatabase Transaction Model for Interbase, Proc. of the 16th VLDB Conference, August, 1990.

....of its ontology . The megaprogramming language should offer constructs to supply parame ters to modules, initiate computations, and extract and combine results. If one megamodule cannot perform its task, another megamodule that offers the same service may be used instead (function replication [3]) Communication and concurrency are central to a megaprogramming language. Our proposal for a megaprogramming language emphasizes the importance of coordination, as for example provided by the Linda model [5] Linda introduces an asynchronous communication mechanism via shared structured data ....

Ahmed K. Elmagarmid, Yonghou Leu, Witold Litwin, Marek Rusinkiewicz. "A Multidatabase Transaction Model for InterBase". In: Proceedings of the 16th International Conference on Very Large Data Bases, August 1990.

....consistency of MDBS transactions must not be compromised by site nor by communication failures. MDBS transaction rollbacks should be avoided, since MDBS transactions tend to be long lived and costly. Function replication improves the availability of MDBS transactions. The Flex Transaction Model [9, 17] can be used for the specification of alternative services. However, a more fundamental necessity for MDBS is a communication concept that tolerates failures. In this paper we propose the use of a distributed coordination kernel that maintains communication objects which can be shared between ....

.... The maintenance of global atomic commitment is a critical issue in MDBS transaction management [4] Execution of MDBS transactions requires a communication framework with the following properties: ffl order preserving of messages so that internal dependencies like failure or success dependencies [9] between subtransactions can be controlled, ffl atomic write of distributed objects to implement a global atomic commitment, ffl reliability of the communication so that neither site nor network failures can compromise the correctness of a global transaction execution, ffl support of reliably ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz, "A Multidatabase Transaction Model for InterBase," in Proceedings of the 16th International Conference on Very Large Data Bases, August 1990.

....in ORBWork. A mechanism for dealing with errors in an ATM for long running activities was proposed in [DHL90, DHL91] It supported forward error recovery such that errors occurring in nonfatal transactions could be overcome by executing alternative transactions. The work on flexible transactions[ELLR90, ZNBB94] discusses the role of alternate transactions that can be executed without sacrificing the atomicity of the overall global transaction. A workflow system that implements a flexible transaction model has been discussed in [AAA 96] In the work on nested process management systems ....

A. K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In Proc. of the 16th. Intl. Conference on Very Large Data Bases, pages 507--518, Brisbane, Australia, August 1990.

....a brief description of how Interactions are specified. An Interaction is programmed in terms of actions, that dictate what needs to be done to accomplish its task. These actions are grouped together into blocks that are executed together as atomic global transactions. As with Flex Transactions [8], the Interaction can specify different ways to accomplish the task, depending on the multidatabase state. 2.3.1 Actions, Global Transactions and Steps An action is a partially ordered set of steps each of which accomplishes the same objective. Exactly one step must succeed for the action to ....

....to claim the ticket money. If no compensating code blocks succeed, the default could be to allow the user to fix the problem himself. This ability to do less than optimal compensation steps we call sloppy compensation . 6. 2 Dealing with Flexible Transactions Flexible transaction models such as [10, 8, 25, 22] allow the execution flow of an open nested transaction to depend in part on the information in the database. For example, a flexible transaction may allow the same goal to be accomplished in different ways, such as getting a United flight or a TWA flight (with United preferred) The differences ....

[Article contains additional citation context not shown here]

A. K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for InterBase. In VLDB Proceedings, pages 507--518, 1990.

....databases, and algorithms for the management of replicated data in distributed systems. In this section, we compare our approach with representative contributions to each of these fields. Various multidatabase architectures have been proposed in systems such as Omnibase [32] Interbase [20], A la carte [16] and GTE s Distributed Object Management [7] project. All of these systems share the approach in our framework of using liaison processes and wrappers to provide access to heterogeneous database management systems. The Local Access Manager of Omnibase and the Remote System ....

A.K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for InterBase. In Proceedings of 16th International Conference on Very Large Data Bases, pp. 507-518, Brisbane, Australia, August 1990.

....Moreover, we introduce the notion of a transaction closure [13] as a generalized transaction structure consisting of a set of transactions which are (transitively) initiated by the same (root) transaction. Well known advanced transactions such as nested transactions [12] flexible transactions [6], or ConTracts [15] can be seen as transaction closures with special dependencies among the transactions of this closure. A nested transaction, for example, is a transaction closure where the subtransactions must not leave the scope of its initiating transaction. In contrast to nested ....

A. K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In D. McLeod, R. Sacks-Davis, and H.-J. Schek, eds., Proc. 16th Int. Conf. on Very Large Data Bases, pp. 507--518, Morgan Kaufmann, 1990.

....of a production line. At present, this information is all embedded in application programs, as described in the next subsection. It is worth noting that the idea of assigning states to materials contrasts with transactional workflow, in which states are assigned to long running activities (e:g: [48, 1, 58, 21]) This difference might be resolved if each material were associated with a single long running activity. This activity would exist as long as the material is being processed, and would correspond to the sequence of workflow steps that process the material. In this case, material state and ....

Elmagarmid A, K, Y. Leu, W. Litwin, and M. Rusinkiewcz. A multidatabase transaction model for interbase. In Proceedings of the International Conference on Very Large Data Bases (VLDB), pages 507--518, Brisbane, Australia, August 13--16 1990.

....T 1 commits ignore a failed component. This was achieved fairly easily since the vitality of a component was manifested by the presence of an abort dependency of the saga transaction on the component transactions. Unfortunately, this is not sufficient when alternative transactions [BHMC90, ELLR90] and contingency transactions [BHMC90] are considered. For example, if two components exist where one is an alternative of the other, then both of them have to commit in order for the saga to commit. This contradicts the at most one semantics of alternative transactions both alternatives ....

Elmagarmid, A., Leu, Y., Litwin, W., and Rusinkiewicz, M. A Multidatabase Transaction Model for InterBase. In Proceedings of the 16th International Conference on VLDB, pages 507--518, 1990.

....and, according to definition of compensation, to s, and therefore is consistent. A somewhat more general solution in the form of a horizon of compensation, has been proposed in [Krychniak et al. 1996] in the context of multi level activities. 1.2. 5 Flexible Transactions Flexible Transactions [Elmagarmid et al. 1990, Zhang et al. 1994] have been proposed as a transaction model suitable for a multidatabase environment. A flexible transaction is a set of tasks, with a set of functionally equivalent subtransactions for each and a set of execution dependencies on the subtransactions, including failure ....

....have been proposed to address many such issues in which failure atomicity requirements have been relaxed. Compensation has been applied to tasks and groups of tasks (spheres) to support partial backward recovery in the context of the FlowMark WFMS [Leymann, 1995] Work on flexible transactions[Elmagarmid et al. 1990, Zhang et al. 1994] discusses the role of alternate transactions that can be executed without sacrificing the atomicity of the overall global transaction. This provides a very flexible and natural model for dealing with failures. These concepts are applicable in workflow environments also. A ....

Elmagarmid,A. K., Leu, Y., Litwin, W., and Rusinkiewicz, M. (1990). A Multidatabase Transaction Model for InterBase. In Proc. of the 16th. Intl. Conference on Very Large Data Bases, pages 507--518, Brisbane, Australia.

....retriable, or pivot, and at most one subtransaction can be pivot. In [ZNBB94] it was shown that this class can be extended by specifying global transactions as exible transactions. Flexible transaction models, such as ConTracts, Flex Transactions, S transactions, and others [DHL91, ELLR90, BDS 93] increase the failure resilience of global transactions by allowing alternate subtransactions to be executed when an LDBS fails or a subtransaction aborts. In a non exible transaction, a global subtransaction abort is followed either by a global transaction abort decision or by a ....

A. K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In Proceedings of the 16th International Conference on Very Large Data Bases, pages 507-581, Brisbane, Australia, August 1990.

....the task coordination requirements. In general, the task can either be statically or dynamically de ned throughout execution. Statically: The tasks and dependencies among them are de ned before execution of the work ow starts. Some of the relaxed transactions (e.g. Flexible Transaction [14] use this approach) A generalization of this strategy is to have a precondition for execution of each task in the work ow, so that all possible tasks and their dependencies are known in advance, but only those tasks whose preconditions are satis ed are executed. Such an approach was reported in ....

....steps and how forward recovery can be handled by making input and output steps persistent. APRICOTS [25] is a prototype implementation of the ConTract model. It does not allow for dynamic work ow and does not support the exible integration of heterogeneous task structures. The Flex model [9, 10, 14] is an early model which relaxes the atomicity and isolation properties of its transactions. A verity of dependencies are possible between sub transactions. The InterBase project at Purdue [9] for example, is based on the Flex model and enables the execution of distributed programs on ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. Multidatabase Transaction Model for InterBase. In Proceedings of the 16th VLDB Conference, 1990.

....regarded as significant events, and so their execution can be controlled by declaring dependencies that refer to them. Thus the required concurrency control is obtained simply by declaring an appropriate set of ticket access dependencies. 6.2. Flexible Transaction Safety A flexible transaction [11] is defined as a set of subtransactions and their scheduling preconditions along with a set of conditions over their final states [11] These conditions specify the acceptable termination states of the flexible transaction; it completes successfully iff it terminates in such a state. Consider the ....

....concurrency control is obtained simply by declaring an appropriate set of ticket access dependencies. 6.2. Flexible Transaction Safety A flexible transaction [11] is defined as a set of subtransactions and their scheduling preconditions along with a set of conditions over their final states [11]. These conditions specify the acceptable termination states of the flexible transaction; it completes successfully iff it terminates in such a state. Consider the following example, adapted from [21] We have a travel agent flexible transaction, consisting of reserve flight (F ) and reserve car ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz, "A Multidatabase Transaction Model for Interbase," Proceedings of the 16th VLDB Conference, August 1990.

....what T i did. The limited applicability of the saga model for modeling workflows stems from the fact that sagas provides a restrictive control flow and compensation policy that may be too limited to represent the exact semantics of the workflow constraints. Other extended transaction models [ELLR90, KR88, Reu89, HA91, J.91, PAR93, ASN 94, BOH 91] developed since attempt to overcome some of the limitations of the saga model by supporting mechanisms to specify more general control flow (e.g. migrating transactions extend the saga by permitting concurrent execution of the atomic ....

.... migrating transactions extend the saga by permitting concurrent execution of the atomic transactions thereby generalizing the control flow from a linear sequence to an acyclic graph [KR88] and recovery policies (e.g. the flexible transaction model permits functional replication of transactions [ELLR90] Most of the papers on extended transaction models do not discuss implementation issues. That is, they do not address the issue of the design of a transaction manager to support their model. One exception to that is the ConTract model where the authors identify the underlying system issues in ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for interbase. In Proceedings of the Sixteenth International Conference on Very Large Databases, Brisbane, 1990.

....to be defined and supported quickly, flexibly, and efficiently. The project provided insight into both the strengths and weaknesses of the approach for this class of applications. The transaction processing system described in this paper is based on the Flexible Transaction paradigm [RELL90, ELLR90] A Flexible Transaction is a collection of subtransactions related by a set of execution dependencies among them. Associated with each Flexible Transaction is a set of acceptable states defining the conditions for the success of the global transaction. Therefore, the success of all ....

....application using the Flexible Transaction paradigm and describes the architecture of our prototype for processing Flexible Transactions. Section 5 presents conclusions and future work. 2 Flexible Transaction Model A Flexible Transaction is specified by providing the following information [ELLR90] a) a set of subtransactions, b) a set of intra transaction execution dependencies, and (c) a set of acceptable states defining the conditions for the success of the Flexible Transaction. 2.1 The Set of Subtransactions Each subtransaction is a logical unit of work that performs some ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for Interbase. Proceedings of the 16th VLDB, August 1990.

.... (the resources are divided) and later join another transaction (the resources are merged) Split transactions provide a mechanism for direct resource transfer, and provide adaptive recovery (a part of the work may be committed before completion of a transaction) Flexible Transactions [42, 16] have been proposed as a transaction model suitable for a multidatabase environment. A flexible transaction is a set of tasks, with a set of functionally equivalent subtransactions for each and a set of execution dependencies on the subtransactions, including failure dependencies, success ....

....in a task. In general they can either be statically defined or determined dynamically during its execution. ffl Statically: In this case the tasks and dependencies among them are defined before the execution of the workflow starts. Some of the relaxed transactions (e.g. Flexible Transactions [16]) use this approach. A generalization of this strategy is to have a precondition for execution of each task in the workflow, so that all possible tasks in a workflow and their dependencies are known in advance, but only those tasks whose preconditions are satisfied are executed. Such an approach ....

[Article contains additional citation context not shown here]

A.K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In Proceedings of the 16th International Conference on VLDB, 1990.

....or programs) In general, dependencies can either be defined a priori (statically) or determined dynamically during its execution. In the first case, the tasks and dependencies among them are defined before the execution of the workflow starts. Some of the relaxed transaction models (e.g. [6], 13] and [7] use this approach. A generalization of the static strategy is to have a precondition for execution of each task in the workflow or specific transitions of the tasks, so that all possible tasks in a workflow and their dependencies are known in advance, but only those tasks whose ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In Proceedings of the 16th International Conference on VLDB, 1990.

....of multiple databases. Multidatabase transaction management addresses the issues of global and local consistency in such an environment. However, one problem with the concepts of nested transactions [Mos85] and multidatabase transactions (e.g. contracts [Reu89] flexible transactions [ELLR90] and multitransaction activities [GMGK 90] is the assumption that all subtransactions, as well as all execution dependencies between them are known in advance. While such assumptions may be realistic in some cases, they limit the applicability of these concepts in environments consisting ....

....properties is atomicity which may not be required if some of the operations are compensable. In such a case, if it is determined later that the operations should not have been executed, their effects can be undone by issuing compensating operations. For example the flexible transactions in [ELLR90] allow specification of alternative actions that can be invoked when some actions fail. A multidatabase transaction may accomplish its objectives even if some of its actions (or subtransactions) are not executed successfully. Sometimes, the interactions of concurrent update transactions require ....

[Article contains additional citation context not shown here]

A. Elmagarmid, Y. Leu, W. Litwin and M. Rusinkiewicz. A Multidatabase Transaction Model for InterBase. In Proceedings 14.6 Bibliography 25 of the 16th International Conference on Very Large Databases, August 1990.

....language prototypes according to the way they support inter process communication and concurrency. We show languages belonging to different paradigms. In the following two sections we present the IPL and VPL languages. They have in common that their design is based on the Flex Transaction Model [ELLR90, KPE92]. The language IPL (InterBase Programming Language) is presented in Section 1.4. The coordination language V PL (Vienna Parallel Logic) is presented in Section 1.5. A comprehensive example shows the realization of an entire MDBS, representing a travel agency, in VPL . 1.2 Languages in the MDBS ....

....IPL 13 1.4 The Transaction Language IPL 1.4. 1 A Brief Introduction to the Flex Transaction Model Many researchers have proposed alternative transaction models for MDBS transactions which can tolerate the failure of individual subtransactions [Elm92] For example, the Flex Transaction model [ELLR90] relaxes the atomicity and isolation properties of nested transactions to provide increased flexibility in transaction specification. Consider a transaction that is composed of a set of tasks. For each task, the Flex Transaction model allows the user to specify a set of functionally equivalent ....

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for InterBase. In Proceedings of the 16th International Conference on Very Large Data Bases, pages 507--581, Brisbane, Australia, August 1990.

No context found.

A. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabase transaction model for InterBase. In Proc. of the Int. Conference on Very Large Databases, Brisbane, Australia, 1990.

No context found.

A.K.Elmagarmid, Y.Leu et all. A Multidatabase Transaction Model for InterBase. In Proceedings of the 16 th International Conference on VLDB, 1990

No context found.

A. Elmagarmid, Y. Leu, W. Litwin and M. Rusinkiewicz. A multidatabase Transaction Model for interbase. Proc 16th VLDB, Brisbane 1990.

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