Gray, J. and Reuter, A. (1993) Transaction Processing. Morgan Kaufmann Publishers, San Mateo, CA.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....where it is possible to wrap up a set of actions to restore the critical section s invariant. It is 81 less suitable for more complex critical sections, particularly if interactions with other sessions or the network, etc. occur during the section. Transaction logging: The use of transactions [Gray93] in database systems and distributed systems to provide the ACID properties has been heavily researched. Each set of operations on shared state is packaged up into a transaction. Upon completion of the transaction, the operations are committed or aborted as a single group; if the transaction ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann Publishers,

....5.3. For a discussion of some algorithmic approaches to fault tolerance, see [6] in this collection. A large body of knowledge known as transaction processing is concerned with fault tolerance and the various solutions to the problem of reliable computing in the presence of failures (see, e.g. [7]) Methods for fault tolerant transaction processing often rely on maintaining redundant or duplicated state between two parties (often processes) if one of these processes fails, the other can continue the computation because no information has been lost. Most approaches to fault tolerance have ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann Publishers, San Mateo (CA), USA, 1993.

.... different node that is up (which is the job of the load manager) Extension: Preserve queries in progress This extension essentially requires a transaction processing monitor (TP Monitor) which is a transactional RPC mechanism that is responsible for retrying RPCs that fail on a different node [GR97]. An IP based implementation would be to mirror TCP state information so that a failed connection can be replayed to a new node, but this is extraordinarily difficult in practice and we know of no real systems that do this [note to referees: Sun s full moon clustering project may do this, but we ....

J. Gray and A. Reuter. Transaction Processing. MorganKaufman, 1997.

....1999] and Web based systems [Zhong and Zhou 1998] and investigates issues involved in the integration of these technologies in our Web based application. Replication is the key to providing high availability, fault tolerance, and enhanced performance in a distributed system. programs [Gray and Reuter 1993, Baentsch et al. 1996, Duan 1996] However, although considerable research efforts have been directed towards the design of replication control protocols, replication is still viewed as a necessary evil [Triantafillou and Taylor 1995] Most of the existing replication control protocols are ....

J. Gray and A. Reuter, Transaction Processing, Morgan Kaufmann Publishers, USA, 1993.

....it must become incremental, to cope with envisaged scales, and it may be parallelised to reduce the update from the log at the start of the change over of service platform. 48 Chapter 10 Transactions The word transaction has come to mean, in many people s minds, the ACID transactions of OLTP [92]. Transactions were introduced into database programming for two reasons. To delimit units of work, so that they could be controlled and managed by a DBMS. To provide isolation so that application developers could write code with the illusion that only one instance of their program would ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann, 1993. 88

....lost and money atomicity fails. Note, however, that the only party to suffer was the party that failed; there is no loss to the consumer nor the bank. Our failure model for agents, other than banks, will be based upon the notion of commitment points, as used in standard database transactions [7, 16, 8]. We assume that each agent (other than the bank) has a particular point in the protocol at which that agent commits. Before this point is reached, we allow an agent to abort the protocol freely. After the commitment point, we consider only failures in an agent if the failure can potentially ....

J. Gray and A. Reuter. Transaction Processing. Morgan-Kauffman, 1993.

....We introduce buffer management at this point because the design of the buffer manager has great influence on the requirements for coherency control and recovery described in Sections 2.5 and 2.6. The buffer management policy is chosen so that it introduces as little disk overhead as possible [GR93] When a transaction wants to access a data item the item must first be present in the database buffer in main memory. The database buffer is divided into slots where each slot can hold a page. In a shared disk environment all nodes have their private data buffers that are managed independently ....

....state when the hardware fails. These mechanisms collect information during normal processing, called logging, and use this data to recover from failures. Most methods and algorithms described in this section are based on ARIES [MHL 89] Other descriptions are derived from [BHG87] and [GR93] We first discuss typical failure types and the resulting recovery requirements. Next, we introduce the logging scheme we have used for our simulation model. The subsequent sections describe the recovery process, and how checkpoints can be used to shorten the recovery process. At the end, we ....

[Article contains additional citation context not shown here]

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann, 1993.

....an extension of the DCE Directory Service to provide a better faulttolerant service. However, it can only solve the fault tolerance problem on one service. It has been suggested that the use of replication and transaction techniques can provide an environmentfor developing reliable programs [12]. Replication is the key to providing high availability, fault tolerance, and enhanced performance in a distributed system. However, although considerable research effort have been directed towards the design of replication control protocols, replication is still viewed as a necessary evil [6] ....

.... with an associated collection of objects, where an object can be a database file, an entry of a database file, or can model a real world entitysuch as printers or actuators of a control system) and all operations must be performed in suchaway that either all of them execute or none of them do [12]. Transactions are used to provide reliable computing systems and a mechanism that simplifies the understanding and reasoning about programs. There have been some efforts to combine twoofthe three techniques ; RPC, replication, and transaction ; together to achieve reliable computing. However, ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann Publishers, San Mateo, California, USA, 1993.

....its operations during a network partitioning. When the network partitioning is recovered, a reconciliation process will bring the system to a consistent state. It has been suggested that the use of replication and transaction techniques can provide an environment for developing reliable programs [Gray and Reuter 1993, Baentsch et al. 1996] Replication is the key to providing high availability, fault tolerance, and enhanced performance in a distributed system. However, although considerable research efforts have been directed towards the design of replication control protocols, replication is still viewed as a ....

J. Gray and A. Reuter, Transaction Processing, Morgan Kaufmann Publishers, USA, 1993.

....buddy server to perform the operation as well. When the buddy returns successfully, the call commits (the server and its buddy actually perform the call) and the result returns to the client. To ensure the consistency of the objects managed by the server and its buddy, a two phase commit protocol[9] is used when executing the nested RPC. Like a service providing server, when an object managing server fails, an RPC to this server will be automatically re directed to its buddy server by the system. All buddy servers are simple servers. That means, when a server (service providing or object ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann Publishers, San Mateo, California, USA, 1993.

....if there is an exclusive lock taken on x. If check read(x) must wait for x s creator to commit, it simply waits for the release of this lock. We show that these mechanisms are easily implemented on top of an existing MV2PL lock manager. We take a lock manager similar to the one described in [GR93] For simplicity we only consider exclusive locks (noted X lock) and shared locks (noted S lock) The lock manager s data structures are summarized in Figure 8. Its two basic interfaces are lock and unlock. The only change in the lock manager s data structures consists of associating to each lock ....

....of lock queue traversal and memory space, since instead of enqueuing new lock requests, it (sometimes) appends the caller s pid into a list. The number of locks in the system is thus reduced. We give in Appendix 1, the pseudocode for check read, assuming the implementation context described in [GR93] 4 Application to Integrity Checking In this section, we describe how EMV2PL can be used to optimize the enforcement of semantic integrity constraints in database applications. Until now, the vast majority of database applications implement integrity constraints using a procedural approach ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann, 1993.

....if there is an exclusive lock taken on x. If check read(x) must wait for x s creator to commit, it simply waits for the release of this lock. We show that these mechanisms are easily implemented on top of an existing MV2PL lock manager. We take a lock manager similar to the one described in [GR93] For simplicity we only consider exclusive locks (noted X lock) and shared locks (noted S lock) The lock manager s data structures are summarized in Figure 4. Its two basic interfaces are lock and unlock. The only change in the lock manager s data structures consists of associating to each lock ....

....of lock queue traversal and memory space, since instead of en queuing new lock requests, it (sometimes) appends the caller s pid into a list. The number of locks in the system is thus reduced. We give in Appendix 1, the pseudo code for check read, assuming the implementation context described in [GR93] 3 Application to Integrity Checking We showed through the examples of section 1 that EMV2PL allows to avoid constraint anomalies. However, the applicability of EMV2PL suffer from the following limitations: i)the transactions must be write then read transactions and, ii) the lockpoint (i.e. ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann, 1993.

....But in this case, the consumer has locked up her funds. If the merchant did not receive her payment, then the consumer may be waiting for a very long time A standard approach to addressing the question of reliability is the notion of ACID (atomic, consistent, isolated, durable) transactions [10]. In the distributed systems community, ACID transactions have been widely adopted as the standard mechanism for realizing distributed transactions. ACID transactions are the payment transactions should be failureatomic, so that failures in parts of the system will not leave the entire system in ....

....atomic. The obvious question is: are anonymous atomic transactions possible [16] This has been an open question. Our first attempt to solve this question would be to use standard techniques to make a digital cash transaction atomic. The standard method for doing this is two phase commitment [1, 9, 10, 11, 12]. In short, in two phase commitment, one party assumes the role of transaction coordinator. That party knows and records the identities of all other parties in a non volatile log. Each of the parties records its state before the transaction begins. As the transaction moves forward, various parties ....

[Article contains additional citation context not shown here]

J. Gray and A. Reuter. Transaction Processing. Morgan-Kauffman, 1993.

....4: Flowgraphs of transaction (2.1) 3 The Evaluation Model 3.1 Dynamic Dependency The definition of a nested transaction and the associated flowgraph only captures the structural dependencies among flat transactions of a nested transaction. There is another dependency, the dynamic dependency [4], that needs to be addressed when evaluating the performance of a nested transaction. Dynamic dependency arises from two factors: the use of routing strategy and the use of shared data. For example, if all flat transactions of Figure 2(b) the P block) are routed to different database servers, ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann Publishers, San Mateo, California, USA, 1993.

....coin is effectively lost and money atomicity fails. Note, however, that the only party to suffer was the party that failed; there is no loss to the consumer nor the bank. Our failure model for non agents will be based upon the notion of commitment points, as used in standard database transactions [6, 14, 7]. We assume that each agent (other than the bank) has a particular point in the protocol at which that agent commits. Before this point is reached, we allow an agent to abort the protocol freely. After the commitment point, we consider only failures in an agent if the failure can potentially ....

J. Gray and A. Reuter. Transaction Processing. Morgan-Kauffman, 1993.

....field. The concept of a transaction and its associated ACID (Atomicity, Consistency, Isolation and Durability) properties were developed so that units of work can be viewed as atomic actions to support concurrent accesses and or updates to database objects by multiple executing transactions (Gray and Reuter, 1993). A multidatabase system (MDS) can thus be viewed as a facility that enables a global application to access distributed database objects stored in multiple autonomous database systems such as relational, object oriented and multimedia databases (Rusinkiewicz and Georgakopoulos, 1991) The basic ....

Gray, J. and Reuter, A. (1993). Transaction Processing. Concepts and Techniques. San Manteo:California. Morgan Kaufmann Publishers.

....schedulers would abort. The proposed scheduler strikes a balance between an optimistic (aggressive) and a conservative scheduler. Unlike many other proposed schedulers, our scheduler does not require any data structures other than those used by a typical S2PL scheduler (excellently described in [Gray, Reuter 93] We describe two versions of the SO scheduler: one that does not use deferred updates and another that does. We show that without deferred updates, a handshake between the scheduler and the database manager has to be implemented. This, however, requires only a slight modification to the ....

....ensure the S2PL and SG subschedulers produce compatible serialization orders, it does not actually need to maintain a serialization graph. All required information is available in the S2PL lock manager data structures. A typical implementation of lock manager data structures is shown in Figure 1 [Gray, Reuter 93] We added a read latch on the Lock header. Its use is described in Procedure 1 below) The proposed scheduler works as follows: Procedure 1: When a r[x] or w[x] operation from transaction T arrives, the scheduler places a corresponding lock entry in the x s lock queue and check if there are any ....

[Article contains additional citation context not shown here]

J. Gray, A. Reuter. Transaction Processing. Morgan Kaufmann Publishers, USA, 1993.

....OFF, in which all triggers are deferred until commit time INRIA Optimizing Active Database Transactions. 5 is called the program part and the second part is called the trigger part. Finally, we assume that transactions are executed in total isolation (corresponding to SQL degree 3 isolation [GR93] We restrict ourselves to a class of triggers, called RCA triggers, whose action part can raise an alert, generate a rollback, or overwrite database items that have already been modified in the program part of the triggering transaction. Before formally defining this class of triggers, a few ....

....to check if there is a X lock taken on x. If check read(x) must wait for x s creator to commit, it simply waits for the release of this lock. We show that these mechanisms are easily implemented on top of an existing MV2PL lock manager. We take a lock manager similar to the one described in [GR93] For simplicity we only consider exclusive locks (X) and shared locks (S) The lock manager s data structures are summarized in Figure 7. Its two basic interfaces are lock and unlock. The only change in the lock manager s data structures consists of associating to each lock header a list of ....

[Article contains additional citation context not shown here]

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufman, 1993.

....to achieve property VAC. The details are given in Section 3. To achieve VAC2, we extend the twophase commitment protocol and develop a robust recovery protocol, which is described in the next section. Various protocols have been designed to satisfy AC1 4 in case that all failures are benign [1, 3, 12]. If the hostile failures are considered, it has been shown that no deterministic solution to the atomic commitment problem exists that can tolerate even a single crash failure [8] It is much more complicated to design protocols to satisfy both AC1 4 and VAC1 2. In this paper, we address this ....

....of the receivers instead of the LSNs (log sequence numbers) in a usual transaction system. The redo log is used to recover those failed transactions. The redo recovery in an electronic currency system is different from those redo algorithms focusing exclusively on recovering from a system crash [18, 3, 12]. The recovery mechanisms in a redo transaction is more complicated than that in an ordinary transaction in the sense that the recovery mechanisms should not only handle recovery from transaction abort and system crashes, but also be able to process uncommitted transaction to force an aborted ....

[Article contains additional citation context not shown here]

J. Gray and A. Reuter. Transaction Processing. MorganKaufmann, 1994.

....records because there is a system failure while updating record number 99,001. But rerunning a transaction which fails because the account number is not valid does not make much sense. One way to use current technology to write a simple chained transaction is to write a mini batch program ( GR93] chapter 4) Here, a special database is created to keep track of context. If a transaction updates some records, it writes the key of the last record updated in the special database. After a failure, that key is read to determine what record to update next. Although this solution is ....

....from the one in which it exited. We need ways to query status of both running and exited scripts. We have avoided rerunning transactions which have aborted for non system reasons, including transactions which have aborted due to process failure. Some of these aborts may be permanent ( Bohrbugs [GR93] no matter how many times the transaction runs, it fails. Others may be Heisenbugs which can be related to timing or overload and may disappear if the transaction is rerun. Rerunning aborted transactions a limited number of times is suggested in [WR] We would like to investigate under what ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufman, 1993.

....a solution to nested transactions with recovery properties, never of them make attention to isolation properties. As a consequence transactions participating to a global activity cannot share data. Attempts have been made to provide advanced features on top of flat transaction models. For example, [GrRe93] showed that nested transactions can be emulated by means of the savepoint notion [SQL92] i.e. aborting a subtransaction means rollbacking the transaction since the last savepoint) However, savepoints do not provide a means to relax critical resources before the end of a long duration ....

....transaction model. These features should not be imposed as new protocols to integrate in existing products, but rather as an independent library which can be exploited by database application developers on top of their usual tools. This library is supported by a specific server or resource manager [GrRe93] called CTM (Cooperative Transaction Manager) CTM provides a powerful open nested transaction model which gives the ability to define various structural dependencies between subtransactions. This model comes with a workspace management protocol to properly control cooperation between ....

[Article contains additional citation context not shown here]

Gray J., Reuter A., Transaction processing, Morgan Kaufmann Publishers, San Mateo, California 1993.

....Two operations conflict if they are from different transactions, access the same object and at least one of them is a write. In order to guarantee correct executions, transactions with conflicting operations must be isolated from each other. For this purpose, different levels of isolation are used [9]. The different levels are a trade off between correctness and performance in an attempt to maximize the degree of concurrency by reducing the conflict profile of transactions. In most systems, locking protocols are used to implement isolation levels. Before accessing an object, a transaction ....

J. Gray and A. Reuter. Transaction Processing. Morgan Kaufmann, 1993.

No context found.

Gray, J. and Reuter, A. (1993) Transaction Processing. Morgan Kaufmann Publishers, San Mateo, CA.

No context found.

J. Gray and A. Reuter, "Transaction Processing", Morgan Kaufmann, 1993.

No context found.

Gray, J. and Reuter, A. (1993). Transaction Processing. Morgan Kaufmann Publishers, San Mateo, California.

First 50 documents

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