Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-01-21
2003-05-06
Vu, Kim (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06560601
ABSTRACT:
FIELD OF INVENTION
The present invention relates to a method of enabling a plurality of data objects to be read consistently in a database.
The invention can be applied to particular benefit in databases where transactions are managed with the aid of two-phase locking, wherein a first phase comprises a request for access to objects affected by the transaction and locking of these objects as soon as access has been obtained, and wherein a second phase comprises commitment of the transaction and the release of all locks that were set in the first phase.
DESCRIPTION OF THE BACKGROUND ART
Transaction management is a fundamental technique in database management processes and is sometimes used to isolate a transaction from other actions or events in the database and to provide a consistent picture of the information contained in a dynamic and changing database.
In the case of a traditional transaction process, those objects used by the transaction during the actual transaction process are blocked so as to prevent their use by other transactions during an ongoing transaction. Other transactions that desire access to the same objects must therefore either wait or abort and try again later on.
The actual work carried out in a transaction includes actions that change an object and/or actions that leave an object unchanged, these actions, or events, being referred to hereinafter as object changing events and object non-changing events. The content of an object can be changed, or updated, by writing the changed content into a new version of the object, or by writing over the old version.
In known techniques, all actions concerning a transaction, both a changing and a non-changing transaction, are carried out prior to “commitment” of the transaction. The term “commit/commitment” of a transaction is well known to the person skilled in this art, and means in simple terms that the transaction informs that the actions or events requested by the transaction and requiring isolation have been carried out. It can also be mentioned that the term commit also typically includes the release of all locks that have been set, although we speak about the release of locks as a separate action in the present document.
The current or existing version of the object prior to the transaction is retained in this current form until no further transactions use that current or existing version any longer. This means that different versions of an object may need to be saved for periods of different duration, depending on which transactions use the versions in question.
Certain applications require access to a database in real time, in a manner which will not block access to objects used with other transactions, particularly with regard to purely reading transactions. It is known in this context to use a database management system that permits access to different objects that are not transaction-bound and that, on the contrary, are fast and non-blocking.
The drawback with such systems is that the user acting in the database cannot proceed in the same isolated manner as that which is possible in a transaction-bound system and cannot be provided with a guaranteed consistent picture of the database.
It is also known that non-blocking transactions can be achieved by managing a well-defined transaction protocol. These transaction protocols, however, are not easily managed and their implementation is complex, process-demanding and/or require a large memory capacity.
Thus, it is known either to provide a database that can be implemented quickly and simply but which will not always be able to guarantee a consistent picture of the database, in other words correct result, or to provide a database that while being management positive and showing a correct picture is both slow and ponderous in use.
Databases that are based on so-called optimistical control of concurrent transactions where no locks are used are also known to the art. This control is based on allowing all transactions with the assumption that no conflict will occur.
More specifically, an optimistical control of concurrent transactions means that a check is made to ensure that no conflicts will occur in conjunction with a transaction prior to the transaction being “committed”. If a conflict is found to exist, the transaction is aborted. Otherwise, commitment of the transaction is allowed. It should also be mentioned that two different locks are usual in so-called two-phase locking, or locking in two phases.
A first lock is a so-called shared lock which is set by purely reading transactions with regard to a data object and which allows other reading transactions to have access to said object, but which locks the object to changing transactions.
A second lock is a so-called exclusive lock which is set by transactions that change the data object and which locks the object with regard to all other transactions.
The following publications disclose examples of earlier known techniques, in which different types of non-blocking transactions are exemplified.
U.S. Pat No. 4,627,019
This publication describes a database where an index covering the various objects it the database shows where the different objects are found. When an object-changing transaction is started, the transaction is referred to a new position in the database in which the changed objects shall be stored. A new index that points to the new positions of the changed objects is created.
The old index is retained and still points to the old positions of respective objects.
Each version of an earlier index is kept alive for as long as some transaction uses this version of the index.
Although this transaction management provides a non-blocking transaction protocol, it requires a large amount of memory space, since several different versions of the index can exist in parallel. Implementation of the transaction management is also relatively complex.
EP-A2-0 471 282
This publication describes the introduction of three new types of lock, to wit cash lock, pending lock and out-of-date lock. When a first transaction, a reading transaction, sets a lock on different objects, a cash lock is set instead of a shared lock. If a second transaction requests an exclusive lock on the same objects whilst the first transaction is still in process, the cash lock is changed to a pending lock.
If the second transaction changes an object with a pending lock, the lock is changed to an out-of-date lock. If the second transaction makes no change in an object, the pending lock is changed to a cash lock when the second transaction is committed.
The first transaction normally continues as long as all locks are cash locks. If any pending lock exists on any of the objects that are affected by the first transaction, the first transaction waits until the pending lock switches to some other lock.
The first transaction can continue when a pending lock changes to a cash lock. If the pending lock changes to an out-of-date lock, this indicates that the object has been changed and the first transaction is subsequently aborted.
Although this method enables a lock to be set that does not block changing transactions, it necessitates the abortion of a commenced reading transaction due to a data object changing transaction having changed an object whilst performing the reading transaction.
SUMMARY OF THE INVENTION
Technical Problems
When considering the earlier standpoint of techniques as described above, it will be seen that a technical problem resides in enabling transaction management in which the time period over which an allocated lock blocks an object changing transaction to be greatly shortened.
Another technical problem is one of shortening the time period between setting an allocated lock and releasing said lock for a non-changing transaction.
A further technical problem is one of providing unlimited access to objects used by a non-changing transaction with respect to time, without blocking objects affected by changing transactions during this access time, i.e. a non-blocking access after a lock set by the transaction has been released.
It wil
Hwang Joon Hwan
Vu Kim
LandOfFree
Database transaction with locking in two phases and multiple... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Database transaction with locking in two phases and multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database transaction with locking in two phases and multiple... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3044530