Using a resource manager to coordinate the comitting of a...

Details Using a resource manager to coordinate the comitting of a... Using a resource manager to coordinate the comitting of a...

1999-03-10

2004-05-18

An, Meng-Al T. (Department: 2127)

Electrical computers and digital processing systems: virtual mac

Task management or control

C718S101000, C718S102000

Reexamination Certificate

active

06738971

ABSTRACT:

FIELD OF THE INVENTION
The present invention generally relates to distributed computing systems, and more specifically to using a resource manager to coordinate the committing of a distributed transaction.
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 a distributed transaction system where distributed transactions may specify updates to related data residing on different resource managers. In this context, a distributed transaction is a transaction that includes a set of operations that need to be performed by multiple resource managers. A resource manager, in turn, is any entity that manages access to a resource. Examples of resource managers include queues, file server systems and database systems.
To accomplish a distributed transaction that involves multiple resource managers, each of the resource managers is assigned to do a set of operations. The set of operations that need to be performed by a given resource manager is generally referred to as a child transaction. For example, a particular distributed transaction may include a first of set operations that need to be performed by a first resource manager and a second set of operations that need to be performed by a second resource manager. In distributed systems, the first and second sets of operations are generally referred to as first and second child transactions.
One approach for ensuring data consistency during distributed transactions involves processing distributed transactions using a two-phase commit mechanism. Two-phase commit requires that the transaction first be prepared and then committed. During the prepare phase, the changes specified by the transaction are made durable at each of the participating resource managers. If all of the changes are made without durable error at each of the participating resource managers, then the changes are committed (made permanent). On the other hand, if any errors occur during the prepare phase, indicating that at least one of the participating resource managers could not make the changes specified by the transaction, then all of the changes at each of the participating resource managers are retracted, restoring each participating resource manager to its state prior to the changes. This approach ensures data consistency while providing simultaneous processing of the changes.
In certain distributed computer systems, an application program, or separate tp-monitor is used to coordinate the processing of a two-phase commit for distributed transactions. For the purpose of explanation, the processing of distributed transactions shall be described in the context of a distributed transaction in which the resource managers involved in the distributed transaction are database systems. For example,
FIG. 1A
illustrates a distributed database system
100
in which distributed transactions can be performed. As depicted, distributed database system
100
includes an application program
108
and a plurality of database systems
104
and
106
. Application program
108
interacts with database systems
104
and
106
to perform distributed transactions that involve access to data managed by database systems
104
and
106
.
Database systems
104
and
106
respectively include database server processes
110
and
112
, and nonvolatile memory areas
114
and
116
. Nonvolatile memories
114
and
116
represent nonvolatile storage, such as a magnetic or optical disk, which can be used to durably store information. In this example, nonvolatile memories
114
and
116
respectively include databases
130
and
132
. Database
130
includes a log
118
and an employee table
126
. Database
132
includes a log
120
and a department table
128
.
Database servers
110
and
112
respectively manage the resources of database systems
104
and
106
. Database systems
104
and
106
may be either homogenous or heterogeneous systems. For example, database systems
104
and
106
may both be Oracle® database server systems. Alternatively, database system
104
may be an Oracle® database server system while database system
106
may be an IBM® database server system such as DB2®. Although not shown, database systems
104
and
106
generally include an application program interface (API) that allows them to communicate with application program
108
using their native protocol language.
Application program
108
includes a set of one or more processes that are used to coordinate the execution of distributed transactions on database systems
104
and
106
. In coordinating the execution of a distributed transaction, application program
108
communicates with database systems
104
and
106
using the native language of each of the respective database systems. For example, if database system
104
is an Oracle database system, application program
108
may communicate with database system
104
using a communication protocol such as the Oracle Call Interface (OCI) protocol. Optionally, if database system
106
is an IBM DB2 database system, application program
108
may communicate with database system
106
using a communication protocol such as the SQL/DS protocol.
To coordinate a two-phase commit sequence, application program manager
108
first prepares the various child transactions of the distributed transaction at the database servers that are responsible for performing the child transactions. After the application manager
108
has determined that all of the database servers have prepared their respective child transactions, the application program informs all of the database servers to commit the child transactions. If any database server is unable to complete its child transaction, then the application program informs all of the database servers to roll back their respective child transactions.
Because application
108
is responsible for coordinating the processing of distributed transactions between database systems
104
and
106
, application program
108
is typically required to store “participation” information in nonvolatile memory. In general, the participation information includes the list of resource managers that are participating in the distributed transaction (“participants”) and a set of identifiers for identifying the child transactions. This participation information is stored before the application program sends the prepare commands to the participants in the distributed transaction. To maintain the participant information, application
108
includes a log
124
within a nonvolatile memory area
122
. If the application program fails before sending the prepare commands, the participants will rollback their changes since they were never in the prepared state.
However, if the application program fails after sending the prepare commands, but before sending the commit commands, the application program can use the participation information in its log to query each participant to determine, depending on the outcome of the distributed transaction, whether a commit or rollback command should be sent to the participants.
For example, a user may submit a command though application
108
to add a new employee record into distributed database system
100
for company “A”. In this example, it is assumed that employee table
126
stores personal employee information that needs to be stored for each employee of company A. It is also assumed that department table
128
stores departmental information that needs to be stored for each employee that is currently working at company A.
To add a new employee record, a user submits a command though application
108
to insert the new employee information into distributed database system
100
. Upon receiving the command, application
108
coordinates the execution of a distributed transaction to insert the personal employee information into employee table
126
and the departmental information into department table
128
. For example, the new employee's name and

Affiliated with

Also associated with

Rating

Using a resource manager to coordinate the comitting of a... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Using a resource manager to coordinate the comitting of a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using a resource manager to coordinate the comitting of a... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3197905