Results 1 -
8 of
8
Multi-level transaction management for complex objects: implementation, performance, parallelism
- The VLDB Journal
, 1993
"... ..."
Efficient support for customizing concurrency control in Persistent Java
, 1996
"... We report on the issues raised when designing a customizable locking mechanism for Persistent Java, a type-safe, object-oriented, orthogonally persistent system based on the language Java. Customizable locking mechanisms are supported by locking capabilities. A locking capability is a book-keeper of ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
We report on the issues raised when designing a customizable locking mechanism for Persistent Java, a type-safe, object-oriented, orthogonally persistent system based on the language Java. Customizable locking mechanisms are supported by locking capabilities. A locking capability is a book-keeper of locks that automatically acquires locks with a customizable conflict detection mechanism. It implements the concepts of delegation of locks and ignorable conflicts, automatically keeps track of the dependencies created because of allowance of conflicts, supports querying of details about these dependencies, and supports the setting of user-defined notifications for conflicts that can't be ignored. Locking capabilities don't change the Java language specification, and allow use of any Java classes without changing a single line of their code to implement the body of transactions. We also present several novel techniques to implement efficiently this customizable locking mechanism in a persis...
Transaction Identifiers in Nested Transactions: Implementation Schemes and Performance
, 1997
"... ..."
Detection Arcs for Deadlock Management in Nested Transactions and their Performance
"... Abstract -In this paper, we address deadlock management in nested transactions. In our strategy, deadlocks are detected through the occurrence of cycles in a waits-for graph (WFG). However, the process of looking for cycles in the WFG considering all its nodes and edges can be very time-consuming. ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract -In this paper, we address deadlock management in nested transactions. In our strategy, deadlocks are detected through the occurrence of cycles in a waits-for graph (WFG). However, the process of looking for cycles in the WFG considering all its nodes and edges can be very time-consuming. To accelerate this process, we propose the detection arcs. In essence, a detection arc represents a higher level abstraction embodying a hidden waiting relation between two transactions that is caused by a lock wait. Thus, the deadlock detection process needs to traverse only a minimal subset of the WFG's edges when it is started, the set of detection arcs. Therefore, the overall performance of deadlock management is improved, as confirmed by our performance measurements.
Locking in OODBMS Client Supporting Nested Transactions
- in Proc. of the 11th Int. Conf. on Data Engineering
, 1995
"... Nested transactions facilitate the control of complex persistent applications by enabling both fine-tuning of the scope of rollback and safe intra-transaction parallelism. In this paper, we are concerned with supporting concurrent nested transactions on client workstations of an OODBMS. Use of the t ..."
Abstract
- Add to MetaCart
Nested transactions facilitate the control of complex persistent applications by enabling both fine-tuning of the scope of rollback and safe intra-transaction parallelism. In this paper, we are concerned with supporting concurrent nested transactions on client workstations of an OODBMS. Use of the traditional design and implementation of a lock manager results in a high CPU overhead: in-cache traversals of the OO7 benchmark perform, at best, 4.5 times slower than the same traversal achieved in virtual memory by a nonpersistent programming language. We propose a new design and implementation of a lock manager which cuts that factor down to 1.8. This lock manager supports nested transactions with both sibling and parent /child parallelisms, and provides object locking at a cost comparable to page locking. Object locking is therefore a better alternative due to its higher functionality. 1 Introduction Object-Oriented Database Management Systems (OODBMS) are advocated for complex applica...
On the Cost of Lock Inheritance in Lock Managers Supporting Nested Transactions
, 1994
"... The flexibility of nested transactions is generally provided at the expense of a more complex locking mechanism which must deal with expensive lock inheritance. In this paper, we give a solution for efficient lock inheritance. Our solution does not change the original nested transactions model but d ..."
Abstract
- Add to MetaCart
The flexibility of nested transactions is generally provided at the expense of a more complex locking mechanism which must deal with expensive lock inheritance. In this paper, we give a solution for efficient lock inheritance. Our solution does not change the original nested transactions model but does revisit its locking rules using set-oriented semantics. This allows us to trade the cost of lock propagation at sub-transaction commit for a potentially more complex conflict detection. Then we propose an efficient lock implementation which maintains the overhead of lock requests comparable to the traditional overhead in flat transactions. We conducted a number of comparative measurements in order to evaluate our trade-off. Our benchmarks show a cut off from 7% to 60% of the global time spent in lock operations, which includes lock requests, locks inheritance and release of locks. 1 Introduction The traditional flat transaction model has long been recognised as too limited for complex d...
Customizing Concurrency Controls using Graph of Locking Capabilities
, 1994
"... As persistent object store technology reaches a mature state with respect to orthogonal persistence support, the lack of efficient and flexible concurrency control that could make them an attractive alternative to database systems is cruelly felt. In the search for more flexibility, an increasing tr ..."
Abstract
- Add to MetaCart
As persistent object store technology reaches a mature state with respect to orthogonal persistence support, the lack of efficient and flexible concurrency control that could make them an attractive alternative to database systems is cruelly felt. In the search for more flexibility, an increasing trend towards independent control over the basic transaction properties of atomicity, permanence and serializability has emerged [11, 13]. Following this approach, this paper propose a new mechanism, called locking capability graph, which allows quick prototyping of concurrency control independently of other transaction properties. This mechanism allows (1) generic conflict detection based on a no conflict with relationship between lock owners, (2) arbitrary delegation of locks, and (3), automated tracking of dependencies between lock owners. The mechanism is flexible enough to support a variety of popular transaction models' concurrency control. Our measurements using a first prototype show ...
Lock Inheritance in Nested Transactions
"... The flexibility of nested transactions is generally provided at the expenses of a more complex locking mechanism which must deal with expensive lock inheritance. In this paper, we give a solution for efficient lock inheritance. Our solution does not change the original nested transaction model but d ..."
Abstract
- Add to MetaCart
The flexibility of nested transactions is generally provided at the expenses of a more complex locking mechanism which must deal with expensive lock inheritance. In this paper, we give a solution for efficient lock inheritance. Our solution does not change the original nested transaction model but does revisit its locking rules using set-oriented semantics. This allows us to trade the cost of lock propagation at sub-transaction commit for a potentially more complex conflict detection. Then we propose an efficient lock implementation which maintain the overhead of lock requests comparable to the traditional overhead in flat transactions. We conducted a number of comparative measurements in order to evaluate our trade-off. Our benchmarks show a cut off from 10% to 40% of the global time spent in lock operations, including lock requests and commits. 1 Introduction The traditional flat transaction model has long been recognised as too limited for complex dataintensive application domains l...
