Rez, Theo Harder, "Concurrency Control Issues in Nested Transactions with Enhanced Lock Modes for KBMSs", DEXA'95, 6th International Conference and Workshop on Database and Expert Systems Applications, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....in a Read or Write mode. If the lock is granted, the transaction holds the lock on the object in the requested mode. After completing its work, the parent transaction inherits the locks of the transaction and retains them until its completion. General locking rules are listed below [HaerRoth 93, RezHaer 95, Moss 85] 49 1. Subtransaction S may acquire a read lock on an object O if: ffl no other subtransaction holds a write lock on O, and ffl all subtransactions that retain a write lock on O are ancestors of S. 2. Subtransaction S may acquire a write lock on an object O if: ffl no other ....

....scheme guarantees serializable, and therefore isolated, execution of nested transactions. Both intra transaction and inter transaction parallelism are guaranteed by this model. In terms of intra transaction parallelism, both parent child and sibling parallelism are utilized as well [HaerRoth 93, RezHaer 95, Moss 85] The first and second rules state that a subtransaction can lock a data item if no other subtransaction holds a conflicting lock on the same data item and if 50 all subtransactions that retain a conflicting lock on the data item are ancestors of the lock requesting subtransaction. ....

[Article contains additional citation context not shown here]

Rez, Theo Harder, "Concurrency Control Issues in Nested Transactions with Enhanced Lock Modes for KBMSs", DEXA'95, 6th International Conference and Workshop on Database and Expert Systems Applications, 1995.

....on an object in a Read or Write mode. If the lock is granted, the transaction holds the lock on the object in the requested mode. After completing its work, the parent transaction inherits the locks of the transaction and retains them until its completion. General locking rules are listed below [HaerRoth 93, RezHaer 95, Moss 85] 49 1. Subtransaction S may acquire a read lock on an object O if: ffl no other subtransaction holds a write lock on O, and ffl all subtransactions that retain a write lock on O are ancestors of S. 2. Subtransaction S may acquire a write lock on an object O if: ffl no ....

....This scheme guarantees serializable, and therefore isolated, execution of nested transactions. Both intra transaction and inter transaction parallelism are guaranteed by this model. In terms of intra transaction parallelism, both parent child and sibling parallelism are utilized as well [HaerRoth 93, RezHaer 95, Moss 85] The first and second rules state that a subtransaction can lock a data item if no other subtransaction holds a conflicting lock on the same data item and if 50 all subtransactions that retain a conflicting lock on the data item are ancestors of the lock requesting ....

[Article contains additional citation context not shown here]

Theo Harder, Kurt Rothermel, "Concurrency Control Issues in Nested Transactions",The Journal of VLDB, 2(1), 1993.

....transaction model proposed by Moss [10] There are some different nested transaction types depending on the types of possible lock modes, relationships between relatives locks, lock inheritance, parent reaction to transaction abort. A good taxonomy of the nested model variations can be found at [6]. We do not focus on specific variants and consider the general case with the only one limitation all subtransaction are essential. This mean that the parent could commit only if all of its subtransactions have been committed. In general there are two reasons why concurrency control may cause ....

Theo Harder and Kurt Rothermel. Concurrency control issues in nested transactions. VLDB, 2(1):39--74, January 1993.

....in an independent way. This must be considered in contrast with flat transactions where abortion usually implies 4 losing everything that was done in the whole transaction unit unless some special mechanism is adopted. Such aspect of nested transactions is also known as intratransaction recovery [HR93] ffl If the database is distributed then nested transactions provide a mechanism to distribute activities in different sites. ffl They provide synchronization between concurrently running parts of the same nested transactions, i.e. they can be used to express executions that can be carried in ....

....to distribute activities in different sites. ffl They provide synchronization between concurrently running parts of the same nested transactions, i.e. they can be used to express executions that can be carried in a concurrent way. This aspect is also known as intra transaction parallelism [HR93] ffl In object oriented databases if the execution of a method is seen as a transaction then the execution of methods generates a hierarchy that maps in a convenient way into nested transactions [HH91] ffl Nested transactions gives a great flexibility in terms of safe composition of ....

Theo Harder and Kurt Rothermel. Concurrency control issues in nested transactions. iThe VLDB Journal, 2(1):39--74, January 1993.

....on an object in a Read or Write mode. If the lock is granted, the transaction holds the lock on the object in the requested mode. After completing its work, the parent transaction inherits the locks of the transaction and retains them until its completion. General locking rules are listed below [10, 17, 13]: 1. Subtransaction S may acquire a read lock on an object O if: no other subtransaction holds a write lock on O, and all subtransactions that retain a write lock on O are ancestors of S. 2. Subtransaction S may acquire a write lock on an object O if: Nested Transactions in Real Time Database ....

....restarted. This scheme guarantees serializable, and therefore isolated, execution of nested transactions. Both intra transaction and inter transaction parallelism are guaranteed by this model. In terms of intra transaction parallelism, both parentchild and sibling parallelism are utilized as well [10, 17, 13]. The first and second rules state that a subtransaction can lock a data item if no other subtransaction holds a conflicting lock on the same data item and if all subtransactions that retain a conflicting lock on the data item are ancestors of the lock requesting subtransaction. The third rule ....

[Article contains additional citation context not shown here]

Rez, Theo Harder, "Concurrency Control Issues in Nested Transactions with Enhanced Lock Modes for KBMSs", DEXA'95 Conference.

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