Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-03-12
2001-05-15
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000
Reexamination Certificate
active
06233585
ABSTRACT:
The present invention relates generally to computing systems, and more particularly to a method and apparatus for processing asynchronous transactions in an information system.
BACKGROUND
An information or database system is a repository for a collection of computerized data files (the database). An information system may include database management functions, in the form of a database management system, for allowing one or more users to access, retrieve, and modify information in the database. The database consists of a collection of persistent data that may be used by the application systems of some given enterprise. Typically, many such users may access the database at given time. One function of the database management system is to guard against the many threats presented to the data in the database. Tools for safeguarding database data may include recovery, concurrency, security and integrity tools.
Recovery and concurrency are related notions that involve transaction processing. A transaction is a logical unit of work. A transaction may involve one or more accesses to the database and may include or more updates to information stored in the database. Even though many database actions may be invoked, a transaction is considered to be an atomic unit. Classical transaction processing provides that if a transaction executes some updates to a database and then a failure occurs before the transaction reaches its normal termination, then those updates will be undone.
In order to facilitate transaction processing, the database management system may include a transaction manager. The transaction manager oversees transactions to the database and may use tools such as COMMIT and ROLLBACK operations to provide the atomicity required to support transaction processing. A COMMIT operation signals a successful end-of-transaction, that a logical unit of work, a transaction, has been completed. A ROLLBACK operation signals an unsuccessful end-of-transaction indicating that the database may be in an inconsistent state. Recovery refers to those operations initiated by the transaction manager in response to a ROLLBACK.
Concurrency refers to the interaction of transactions executed by multiple users. A concurrency manager or other concurrency control mechanism may be provided as part of the database management functions to ensure that concurrent transactions do not interfere with each other's operation. A concurrency control mechanism can alleviate problems related to lost updates, uncommitted dependency and inconsistent analysis problems. A more detailed description of concurrency problems is described in “An Introduction to Database Systems”, fifth edition, 1991, by C. J. Date and published by Addison Wesley.
One conventional solution to concurrency problems is the use of locks. Locking provides an assurance that one transaction can rely on the state of a particular portion of a database, and not be concerned with another transaction modifying the state of the data.
Conventional concurrency managers employ two kinds of lock, namely exclusive locks (X locks) and shared locks (S locks). Only one transaction can hold an X lock on a transaction record at a time. Two or more transactions may maintain S locks on the same record. For example, if transaction A holds an exclusive (X) lock on record R, then a request from transaction B for a lock of either type on R will cause B to go into a wait state. B will wait until A's lock is released. If transaction A holds a shared (S) lock on record R. then a request from transaction B for an X lock on R will cause B to go into a wait state (and B will wait until A's lock is released). However, a request from transaction B for an S lock on R will be granted (that is, B will now also hold an S lock on R).
Transaction requests for record locks are normally implicit. When a transaction successfully retrieves a record, it automatically acquires an S lock on that record. When a transaction successfully updates a record, it automatically acquires an X lock on that record. If the transaction already holds an S lock on the record, then the update will “promote” the S lock to X level. X locks are held until the next synchpoint. A synchpoint represents the boundary between two consecutive transactions; it thus corresponds to the end of a logical unit of work, and hence to a point at which the database is (or should be) in a state of consistency. Typically, the only operations that establish a synchpoint are COMMIT, ROLLBACK, and program initiation. S locks are also normally held until the next synchpoint.
The typical role of any transaction service is to ensure the classical ACID properties of transactions. These include; Atomicity, Consistency, Isolation, and Durability.
Atomicity refers to the property of a transaction service in which either all steps of a transaction are done or no steps are done. Consistency refers to the transitioning of data from one well known state to another well known state. The isolation property, as the term suggests, provides that data modifications made within the scope of a transaction are isolated from other transactional data modifications. In other words, intermediate results of a transaction are not “exposed” to other transactions. The durability property ensures that data modifications made within the scope of a transaction are guaranteed to be saved on disk.
In short, it is the job of the transaction service to ensure that state changes to persistent data are made in such a way that they are isolated from state changes made by other processes and can be “recovered” (that is in case of a failure we can restore an object to a well known state). While locking provides guarantees for concurrency, problems arise in processing long-lived or asynchronous transactions. As was described above, locks remain in place until the completion of a transaction and the occurrence of a next synchpoint. However, where long-lived transactions arise, locks to the database can result in inefficient performance. For example, a business transaction may include a request for quotations to be sent out to various suppliers. The transaction will complete at some indeterminate time in the future when one or more of the bids have been returned. Obviously, it would be inefficient to tie up resources in a database while waiting for these type of long lived transactions.
In classical online transaction processing (OLTP) systems, the workload consists of small, short duration transactions that touch a small amount of data and complete (e.g., the classical airline reservation system) very quickly. In systems that exhibit long-lived transactions, the workloads may consist of transactions that touch data that lives across a WAN, or a transaction that references data through a reliable messaging provider (i.e. where the application need not be executing). In either case, the semantics of the workload is radically different then the classical OLTP workload. For these workloads, conventional locking schemes provided by transaction processing systems are woefully inadequate.
SUMMARY OF THE INVENTION
In general, in one aspect, the invention provides a transaction system implemented on a server machine for maintaining consistency in an information system supporting asynchronous transactions. The information system includes a database shared among a plurality of users and implemented on a client machine. The transaction system is invoked at run-time for a transaction where the transaction includes one or more subtransaction steps. The transaction system includes a graphical user interface for receiving a user defined isolation level selection for executing a transaction between the server machine and the database or application, a persistent service for storing object state information for each object affected in the execution of each subtransaction step and a state verification service for verifying the state of each object affected by a subtransaction step to verify the state of the object is the same as a last time the object was seen in the transaction.
Gupta Prashant
Rubin David S.
Black Thomas
Coby Frantz
Crossworlds Software, Inc.
Fish & Richardson PC
LandOfFree
Isolation levels and compensating transactions in an... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Isolation levels and compensating transactions in an..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Isolation levels and compensating transactions in an... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2567007