Elmagarmid A. (Editor). (1991) Special Issue on Unconventional Transaction Management. Bulletin of the IEEE Technical Committee on Data Engineering, 14(1).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....transaction structural properties specify the correctness of subtransactions of individual nested transactions. The search for more flexible correctness requirements is further motivated by the introduction of other transaction models that extend the traditional atomic transaction model. See [Elmagarmid, 1991] for a description of some of the extended transaction models. These extensions came about because the atomic transaction model in conjunction with serializability is found to be very constraining when applied in advanced applications such as design databases that function in distributed, ....

Elmagarmid A. (Editor). (1991) Special Issue on Unconventional Transaction Management. Bulletin of the IEEE Technical Committee on Data Engineering, 14(1).

....applications that involve reactive (endless) open ended (longlived) and collaborative (interactive) activities. Hence, various extensions to the traditional model have been proposed, referred to herein as extended transactions [Mos81, VRS86, BKK85, PKH88, KLS90, GGK 91, BHMC90, FZ89, SZ89, Elm91] Compared to the traditional transaction model, these models associate broader interpretations with the four transaction notions mentioned above to provide enhanced functionality while increasing the potential for improved performance. Upon examining these ad hoc extensions to the traditional ....

Elmagarmid A. (Issue Editor). Special Issue on Unconventional Transaction Management. Bulletin of the IEEE Technical Committee on Data Engineering, 14(1), 1991.

....user can specify that when a certain condition is satisfied, the system should execute the BUY STOCK transaction every 10 minutes (in order to prevent driving up the stock price) as long as the stock price remains below 50. Previously, such temporal actions required extended transactions models ([9, 10, 13]) that must be controlled by an additional software system running on top of the database management system. The temporal condition formalism also requires an additional software system, the condition evaluator, but this is the same system used for rule processing, integrity constraint ....

A. Elmagarmid, editor, Data Eng. Bulletin, Special Issue on Unconventional Transaction Management, March 1991.

....approaches rely on global services that typically are unavailable in federated databases, they are inappropriate for the environment we consider. Note that some approaches focus on relaxing the traditional notion of transaction serializability for constraints in distributed environments, e.g. [BGM92, Elm91], but some level of locking and global query facilities is still expected. A few recent papers have addressed the issue of monitoring constraints in loosely coupled, distributed, and sometimes heterogeneous database environments. One class of work involves local constraint checking deriving ....

A. Elmagarmid (ed.). Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), 1991.

.... work in database constraint management has focused on centralized (for e.g. or tightly coupled and homogeneous distributed databases (for e.g. 1] 2] 3] 4] The multi database transaction approach to constraint management weakens the traditional notion of correctness of schedules [5], 6] This approach cannot, however, handle a situation in which different databases support different interfaces. In modeling time, our work has similarities with some work in temporal databases [7] and temporal logic programming [8] Our approach is closer to the event based specification ....

Ahmed Elmagarmid, editor. Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), March 1991.

....users or multiple concurrent processes. Examples include CAD, office automation, collaborative work, manufacturing control, and workflow management. Such applications combine database transactions, application programs, and other activities into larger information systems and business processes [32, 40, 39, 10, 42, 34, 21, 43, 45]. These applications require new transaction models, new methods of transaction management, and new transaction languages [32, 40, 39, 29] This paper focuses on the latter issue: languages for specifying non classical transactions, and for combining them into complex processes. In particular, we ....

A. Elmagarmid, Ed. Special issue on unconventional transaction management. Bulletin of the Technical Committee on Data Engineering (IEEE Computer Society), 14(1), June 1991.

.... (e.g. 14] tightlycoupled homogeneous distributed databases (e.g. 12, 26] or loosely coupled heterogeneous databases with special constraint enforcement capabilities (e.g. 8,24] The multidatabase transaction approach weakens the traditional notion of correctness of schedules (e.g. [5, 10]) but this approach cannot handle a situation in which different databases support different capabilities. In its modeling of time, our work has some similarity to work in temporal databases [27] and temporal logic programming [1] although our approach is closer to the event based specification ....

Ahmed Elmagarmid, editor. Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), March 1991.

....Protocol in our framework and prove the associated guarantee. This is discussed in Section 6. Another approach to constraint management in multi database environments is to extend the transaction concept to multi databases by suitably weakening the traditional notion of correctness of schedules [Elm91] This approach typically restricts the data items that may be involved in a constraint (e.g. constraints may be over local data only for local serializability [BGMS92] These approaches differ from ours in that with extended transactions there still is no mechanism to allow different ....

A. Elmagarmid, editor. Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), March 1991.

....whenever possible. These are are special cases of the more general framework we present here. 5 Another approach to constraint management in multidatabase environments is to extend the transaction concept to multidatabases by suitably weakening the traditional notion of correctness of schedules [Elm91] This approach typically restricts the data items that may be involved in a constraint (e.g. constraints may be over local data only for local serializability [BGMS92] These approaches differ from ours in that with extended transactions there still is no mechanism to allow different ....

Ahmed Elmagarmid, editor. Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), March 1991.

.... concept of distributed client server computing [GR93] In the past decade, the research topic of extended transaction management (also known as advanced or relaxed transaction management) has emerged in the database community, to extend the transaction concept beyond conventional data processing [BK91, El91, El92, Hsu93]. This research direction is motivated by the following observations: 2 1. Advanced database applications such as engineering, office automation, and management of scientific data exhibit workload characteristics that are quite different from the characteristics of conventional business ....

Elmagarmid, A.K. (Ed.), IEEE Data Engineering Bulletin, Special Issue on Unconventional Transaction Management, Vol.14 No.1, March 1991

.... also guarantees consistency, but in our framework this requires a transaction model that supports rollback across related transactions (i.e. across transactions spawned by enqueue operations) Note that many of the proposed extended transaction models support this or similar capabilities; see [12]. A number of extensions to the dependency specification language are possible. We have restricted our dependencies to operate over exactly two databases, since this appears to be the most common requirement. However, there certainly are scenarios in which the existence or value of data in one ....

A. Elmagarmid, editor. Special Issue on Unconventional Transaction Management, Data Engineering Bulletin 14(1), March 1991.

No context found.

A. Elmagarmid, editor, Data Eng. Bulletin, Special Issue on Unconventional Transaction Management, March 1991.

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