Method for managing distributed savepoints across multiple...

Details Method for managing distributed savepoints across multiple... Method for managing distributed savepoints across multiple...

2001-05-15

2004-11-09

Wassum, Luke S. (Department: 2177)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000

Reexamination Certificate

active

06816873

ABSTRACT:

FIELD OF THE INVENTION
The invention relates to distributed database management systems and to the management of savepoints within distributed database management systems.
BACKGROUND OF THE INVENTION
A database is a storehouse of collected, recorded, and related data, with inherent value in the focus of the data elements, the logical coherency of data, the inherent meaning of the data, and the use to which the data can be put. Additionally, because of the database organization, the accessibility of records and files, and dynamic updatability of the data, the database has value far beyond the value of the sum of the individual elements of the database. The ability to routinely, repetitively, and consistently add data to the database, and to recover relevant, timely, correct data from the database, is a function of its database management system (DBMS). A DBMS is a collection of computer application programs that create the database organization (schema and metadata), and that store, retrieve, and update files in the database. Large databases are managed by complex database management systems (DBMS's) that have mechanisms to assure the timeliness and validity of the data. The mission critical requirement of a DBMS is that the data be correct and be current.
Correct data, that is collected and reported in a timely fashion, is critical to a multi-user database. This is the reason for concurrency control. Concurrency control assures that several users trying to access and update the same data do so in a controlled manner so that the results of the updates are correct, and also assures that readers of the data see current and committed data, not stale or uncommitted data. A typical example is the assignment of individual airplane seats in an airline reservations database. Even with many reservationists assigning many seats on many flights, the concurrency control capability of the DBMS must assure that only one passenger is assigned to one seat, and, conversely, that one seat is assigned to only one passenger
1. DBMS Access Statements
Operations on database files include the “Data Manipulation” operations of SELECT, INSERT, UPDATE, and DELETE, among others.
2. The SELECT operation retrieves data from a database, and returns the data to the requestor.
3. The INSERT operation enters data into a database.
4. The UPDATE operation changes the value of an existing record.
5. The DELETE operation deletes a record from the database.
2. Transaction Processing—Read and Write Operations of a Transaction
Those operations which change the file, as Insert, Delete, and Modify, require “Concurrency Control.” These operations typically follow a Read operation and are a part of a Write operation. Typically the Read operation, e.g., Read_Item(x), reads a database item named “x” into a program value in the end user's program named “x”. The Write_Item(x) operation writes the value of the end user program variable, x, into the database item x.
3. Transaction Processing—Concurrency Control
Concurrency control assures that several end users seeking to modify (insert, update, delete) records substantially simultaneously do so in a controlled manner, so that the data stored in the database is correct. It also assures that readers see current and committed data, rather then stale data or uncommitted data.
4. Transaction Processing and Transaction States
There are various means of controlling concurrency in a single database. Most common, by way of example, is “locking,” so that when one user attempts to modify, update, or delete a record, no other user can access the record until the transaction is completed. A transaction may complete with commitment to the changes made by the transaction (COMMIT) or with reversal of the changes made by the transaction (transaction rollback). The decision to rollback a transaction may be that of the application program or may be a system decision (for example, in response to a condition preventing commit). “Completion” is a non-specific term, and can mean writing the data, or going beyond writing the data to “committing” the transaction, before allowing another user access to the record. Concurrency control results in either (1) “committing” the transaction, or (2) aborting the transaction and “rolling back” the database to a prior state.
In the context of concurrency control, and transaction logging, it is advantageous to break the model of items 1 and 2, above, into more granular levels or transaction states. Thus, the transactions can be broken down into the steps or transaction states of:
1. BEGIN_TRANSACTION which marks the beginning of a transaction.
2. SELECT or INSERT which specify read or write operations on database items as part of a database transaction.
3. END_TRANSACTION which specifies that the SELECT or INSERT operations have ended. These commands mark then end of transaction execution. It is at this point that the DBMS determines if the changes can be “committed”, that is, permanently applied.
4. COMMIT_TRANSACTION which signals a successful end of the transaction, the transaction will be committed to the database, and will not be undone.
5. ROLLBACK or ABORT which signals that the transaction has ended unsuccessfully, and must be rolled back, that is, the changes to the database must be undone.
5. Transaction Processing—System Log
When concurrency control fails, and a concurrency problem arises, it is necessary to “roll back” the failed transactions. Transaction rollback is accomplished using the system log. The system log records transaction information as a transaction progresses. Typically the information includes a transaction ID, and before and after data images for every operation performed by a transaction. The progression of a transaction through stages of COMMIT or ROLLBACK are also recorded on the log.
Logging stops at the “Commit Point”, which is when all operations that access the database have been executed successfully, and the effect of all of the transaction operations on the database have been recorded in the log or journal.
6. Transaction Processing—Recovery and Rollback
If a transaction fails to commit, the database must be rolled back to a previous state, before the failed transaction commenced. This is done by using the journal or log entries to reverse some of the changes in the database, and redo other changes in the database.
7. Transaction Processing—Recovery and Rollback—Savepoints
Savepoints are like bookmarks within a transaction. They may be created by an application between the beginning and end of a transaction. Savepoints allow modifications made to data and schemas since the setting of the savepoint to be undone via a request by the application to “rollback to savepoint”. Savepoints make a set of non-atomic database requests or sub-transactions of an atomic transaction behave atomically, in that they are reversible as a unit. If an application error occurs during execution, or if the application detects an error, the savepoint can be used to undo changes made by the transaction between the time the savepoint was started and the time the savepoint rollback is requested, and return to a prior point in the transaction.
A savepoint is similar to a compound SQL statement, in that it allows grouping several SQL statements into a single executable block. Before the first statement of the block is executed, a savepoint request to start a savepoint block is required. If any of the subsequent statements end in an application error, the DBMS will roll back only that statement. This provides more granularity than a compound SQL statement, in which a single error anywhere in the block causes the entire block to end in an error and rolls back the entire compound SQL statement. At the end of a savepoint block of statements, one can either release the savepoint, or rollback to the savepoint.
Application savepoints provide control over the work performed by a subset of SQL statements in a transaction or unit of work. Within an application one can set a savepoint, and later either release the savepoint or roll back the work perform

Affiliated with

Also associated with

Rating

Method for managing distributed savepoints across 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 Method for managing distributed savepoints across multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for managing distributed savepoints across multiple... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3309805