Performing 2-phase commit with delayed forget

Details Performing 2-phase commit with delayed forget Performing 2-phase commit with delayed forget

1998-12-29

2002-12-10

Jung, David (Department: 2175)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C709S241000, C714S015000

Reexamination Certificate

active

06493726

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to providing atomicty of transactions on a database system, and in particular, to two-phase commits.
BACKGROUND OF THE INVENTION
One of the long standing challenges in distributed computing has been to maintain data consistency across all of the nodes in a network. Perhaps nowhere is data consistency more important than in distributed database systems, where a distributed transaction may specify updates to related data residing on different database systems. To maintain data consistency, all changes made in all database systems by the distributed transaction must be either committed or, in the event of an error, “rolled back”. When a transaction is committed, all of the changes to data specified by the transaction are made permanent. On the other hand, when a transaction is rolled back, all of the changes to data specified by the transaction already made are retracted or undone, as if the changes to the data were never made.
One approach for ensuring data consistency when processing distributed transactions is referred to as “two-phase commit”. According to the two-phase commit approach, one database system (the coordinating database system) is responsible for coordinating the commitment of the transaction on one or more other database systems. The other database systems that hold data affected by the transaction are referred to as participating database systems.
A two-phase commit involves two phases, the prepare phase and the commit phase. In the prepare phase, the transaction is prepared in each of the participating database systems. When a transaction is prepared on a database system, the database is put into such a state that it is guaranteed that modifications specified by the transaction to the database data can be committed. When all participants involved in a transaction are prepared, the prepared phase ends and the commit phase may begin.
In the commit phase, the coordinating database system commits the transaction on the coordinating database system and on the participating database systems. Specifically, the coordinating database system sends messages to the participants requesting that the participants commit the modifications specified by the transaction to data on the participating database systems. The participating database systems and the coordinating database system then commit the transaction. Finally, the participating database systems transmit a message acknowledging the commit to the coordinating database system.
On the other hand, if a participating database system is unable to prepare, or the coordinating database system is unable to commit, then at least one of the database systems is unable to make the changes specified by the transaction. In this case, all of the modifications at each of the participants and the coordinating database system are retracted, restoring each database system to its state prior to the changes.
The two-phase commit ensures data consistency while providing simultaneous processing of modifications to distributed databases. However, these benefits are not achieved without costs. Such costs include network traffic that occurs as a result of transmitting requests to prepare and commit from the coordinating database system to the participants, and of transmitting acknowledgements from the participants to the coordinating database system. Another cost is the increased latency experienced by a database system involved in a distributed transaction in waiting for other database systems to become prepared.
FIG. 1
shows a distributed database system used to illustrate in more detail the costs associated with the two-phase commit performed according to a conventional approach for performing a two-phase commit. Distributed database systems
100
includes a coordinating database system
110
and a participating database system
150
. Database system
110
receives requests for data from database clients
120
, which include client
122
and client
124
. Such requests may be in the form of, for example, SQL statements.
Coordinating database system
110
includes a log, such as log
112
. The log
112
is used to record modifications made to the database system, and other events affecting the status of those modifications, such as commits. Log
112
contains a variety of log records. When these log records are first created, initially they are stored in volatile memory, and are soon stored permanently to non-volatile storage (e.g. a non-volatile storage device such as a disk). Once log records are written to non-volatile storage, the modifications and other events specified by the log records are referred to as being “persistent”. The modifications and events are “persistent” because the permanently stored log records may be used, in the event of a system failure, after the failure to replay the modifications and events to restore the database to its pre-failure state.
For example, log
112
may contain redo records, which are used to record database operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. When a transaction modifies data in a database system, a redo record that specifies the modification is added to the log. To make the modifications permanent, a commit command is issued to database system
110
. In response, database system
110
records the commit in a log record of log
112
referred to as a commit record. When a failure occurs after the redo records and the log record reflecting the commit are stored in non-volatile storage, the database may be modified based on the redo records.
FIG. 2
is a state diagram showing transaction states associated with a transaction as it progresses through the phases of a two-phase commit, and the steps that are performed before transitioning between various transaction states according to a conventional approach for performing a two-phase commit. The transaction states are illustrated using distributed database systems
100
as an example. Transaction states
201
are the transaction states that a transaction goes through within a coordinating database system (i.e. coordinating database system
110
), and transaction states
202
are the transaction states a transaction goes through within a participating database system (i.e. participating database system
150
).
Referring to
FIG. 2
, inactive states
210
,
240
,
250
,
290
represent the inactive state of a transaction being processed on a distributed database system
200
. In the inactive state, there are no database operations specified by the transaction that require any further action (e.g. commit, undo, locking or unlocking of resources needed to perform the operations, such as data blocks). On a given database system, a transaction is initially in the inactive state (i.e. inactive state
210
and
250
), and eventually transitions to the inactive state upon completion (i.e. inactive states
240
and
290
).
A transaction transitions from the inactive state to the active state when a database system receives a “begin transaction” request. For example, client
122
(
FIG. 1
) may issue a BEGIN TRANSACTION request to database system
110
. At step
212
, database system
110
receives the begin transaction request and enters active state
220
. Next, coordinating database system
110
receives a command to modify data on participating database system
150
. In response, at step
221
, coordinating database system
110
transmits a request to participating database system
250
to begin a transaction. At step
222
, coordinating database system
110
transmits one or more requests to participating database system
150
to modify data on participating database system
150
.
At step
252
, participating database system
150
receives the request to begin a transaction. Relative to participating database system
150
, the transaction enters the active state
260
. Afterwards, participating database system
150
receives the request to modify data.
Once a transaction within a database system enters the active state, the database system may receive any number of requests

Affiliated with

Also associated with

Rating

Performing 2-phase commit with delayed forget does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Performing 2-phase commit with delayed forget, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Performing 2-phase commit with delayed forget will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2990136