A pivotal concern in performing database transactions is database integrity. To preserve database integrity, it is important to ensure that transactions observe requirements such as atomicity and isolation. The atomicity requirement mandates that either all or none of the tasks of a transaction be performed, so that incomplete transactions are not applied to the database. The isolation requirement dictates that transactions be handled separately from other transactions, so that no transaction accesses or interferes with an intermediate state of another transaction. Observing the atomicity and isolation requirements prevents transactions from corrupting each other and the database as a whole.
In networked systems, many users and many applications may concurrently seek to perform transactions on the same data. Even in a standalone system, multiple applications may concurrently seek to perform transactions on the same data, possibly with multiple processing threads of each application contending with each other. Because it is difficult to foresee, let alone avoid, all the situations in which in transactions may apply conflicting or inconsistent changes to a database, maintaining database integrity is a significant challenge.
One way to preserve database integrity is to place a lock on a portion of a database used by a current transaction. Placing a lock on the portion of the database prevents other transactions from reading or overwriting the data until the current transaction is complete. Preventing other transactions from reading from the portion of the database ensures that the other transactions will not reach results based on values that the current transaction may change. Correspondingly, preventing other transactions from overwriting that portion of the database ensures that other transactions will not affect the current transaction.
However, although placing a lock on a portion of a database may help to preserve data integrity, it may also result in a countervailing cost. Placing a lock on a portion of a database that a number of transactions seek to access may create a significant backlog of transactions. Some or all of the waiting transactions may not make any changes to a current state of the database, or may not read from, write to, or change particular values that the current transaction uses. Nonetheless, placing the lock on the portion of the database will preserve the integrity of the database, even if it slows access to the database.
One form of lock is a lease. A lease, just as in the case of leases of apartments, buildings, cars, and equipment, is an exclusive grant for a limited period of time. Thus, when a transaction is granted a lease on selected data, the transaction is provided with exclusive access to the selected data for a limited period of time. By limiting the exclusive access to the data to a period of time, if the transaction fails to release the data when the transaction is complete, or the system on which the transaction runs should crash, the data will be unlocked so that other transactions will not have to wait indefinitely to access the data. Conventionally each transaction waiting for the selected data will have to wait until all of the transactions previously queued for the data complete their use of the data, or the leases allocated to each transaction expire.
There can be potentially significant delays as a number of transactions wait for access to leased data. In addition, a system controlling the leasing of data may present a bottleneck in efforts to access data. The system controlling the leases, as a single point of control for data access, may cause transactions delays in attempting to respond to lease requests. Furthermore, because the system may be receiving multiple requests for the same selected data, handling these numerous and potentially repeated requests will waste computing cycles, resulting in further delays to transactions seeking the same data or any other data.