Patent Application
20070118565
The field of invention relates to computing generally; and, more specifically, to two phase commit emulation for non distributed transactions.
The information systems of a modern day enterprise (such as a corporation or government institution) are often responsible for managing and performing automated tasks upon large amounts of data. Persistent data is that data that “exists” for extended periods of time (i.e., “it persists”). Persistent data is typically stored in a database so that it can be accessed as needed over the course of its existence. Here, complex “database software” (e.g., such as DB2, Oracle, and SQL Server) is often used to actually read the data and perhaps perform various intelligent functions with it. Frequently, persistent data can change over the course of its existence (e.g., by executing a series of reads and writes to the data over the course of its existence). Moreover, multiple items of different persistent data may change as part of a single large scale “distributed transaction”.
A distributed transaction is a transaction that involves more than one database or server. Distributed transactions frequently involve multiple databases accessed through multiple servers that are interconnected by a network. Because of the use of multiple databases, distributed transactions are an attempt at some sort of comprehensive function that serves the enterprise's needs. For example, in the case of an airline, a single distributed transaction might be used to manage an internet connection to a potential customer who may reserve a particular seat on a particular flight. Here, note that a number of different databases may be involved in a single distributed transaction that is executed for the customer's experience with the airline's on-line ticketing and reservation system.
For example, assume the distributed transaction is expected to: 1) provide the potential customer with flight scheduling, pricing and seating information; 2) record the customer's name, address, credit card, and email information if any flight is reserved by the customer; 3) update the seating information for each seat reserved by the customer; 4) update the customer's frequent flier mileage records if the customer is registered in the airline's frequent flier program; 5) update the airline's accounting records to reflect the new revenue introduced by each flight reservation made by the customer; and, 6) invoice the customer using the customer's credit card information.
Here, a number of different databases may be involved in the distributed transaction such as: 1) a first database that keeps track of the airline's flight scheduling information; 2) a second database that keeps track of information specific to a particular flight such as seating information; 3) a third database that keeps track of flight pricing information; 4) a fourth flight that keeps track of each customer's name, address and email information; 5) a fifth database that keeps track of each frequent flier's mileage; 6) a sixth database that keeps track of the airline's accounting records; and 7) a seventh database that keeps track of the airline's invoicing records.
a and 1b depict how a distributed transaction is typically carried out by an enterprise's information system infrastructure. A protocol, referred to as the “two-phase commit” protocol is used to ensure that either a distributed transaction's database updates are successfully completed in their entirety; or, the distributed transaction is not effected at all. By ensuring that database updates for a distributed transaction are either completely carried out or not carried out at all, incorrect database records are avoided (e.g., a seat being reserved for a reservation that is not actually made, a seat not being reserved for a reservation that is actually made, etc.).
The example of
Each server 1011 through 1014 includes its own resource manager module 1031 through 1034 that is responsible for communicating with a particular database. The resource manager can often be viewed as driver software that is used to send specific functional commands to the database software in response to requests/commands made by higher level software functions. The commands sent to a database are typically scripted in some form of database language (e.g., Structured Query Language (SQL)). Examples of resource managers include a Java Database Connectivity (JDBC) driver that is presently part of the J2EE platform and an Open Database Connectivity (ODBC) driver provided by Microsoft Corporation.
A transaction manager module 104 is responsible for, typically among other responsibilities, implementing the two-phase commit protocol with those resource managers that communicate to a database that is to be updated after a distributed transaction's calculations have been executed. In the examples of
Once a distributed transaction's calculations are completed so that all database changes to be made as a consequence of the transaction's execution are known (e.g., entry of a specific reserved seat on a specific flight, etc.), the first phase of the two-phase commit protocol begins with the transaction manager 104 receiving a “commit” command 1 from another portion of the distributed transaction's software (e.g., “a client” or “container” that executes higher level functions of the distributed transaction). In response to the received “commit” command 1, the transaction manager 104 sends “prepare” commands 2 to each of the resource managers 1031 through 1034. Note that, because a network 105 resides between the server 1011 that contains the transaction manager 104 and servers 1012 through 1014, those of the “prepare” commands 2 that are sent to servers 1012 through 1014 pass through network 105.
In response to the received “prepare” commands 2, each resource manager forwards a “prepare” command 3 to its corresponding database in the appropriate language format (e.g., SQL). Each database 1021 through 1024 performs what is akin to a “soft write” of the new, updated information. That is, for example, each database runs through all internal routines just short of actually writing the new, updated information. If a problem is not detected by a database (e.g., an incompatibility in the data) just short of the actual write of the updated information, a database reports a “ready” response. In
A “rollback” response means that a database has recognized some problem in preparing itself to actually write its updated information. As a consequence, a “rollback” response essentially means that the new information cannot be written. Given that all new information of distributed transaction must be written or no new information from a distributed transaction may be written, as shall become evident in more detail immediately below, the “ready” response of each server in
In
The transaction manager's sending of a second set of messages in response to the received responses marks the beginning of the second phase. Because the transaction manager 104 receives all “ready” responses from the resource managers 1031 through 1034 in the situation of
In
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
A method is described that comprises executing a non distributed transaction by reading persistent data from a database and performing executions with the persistent data. A prepare command is sent to the database after a change to be made to the persistent data as a consequence of the non distributed transaction's execution is confirmed. A commit command is sent to the database to cause the database to commit the change to the database.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
a (prior art) shows a two phase commit protocol distributed transaction that concludes with all updates being made to their respective databases;
b (prior art) shows a two phase commit protocol distributed transaction that concludes with no updates being made to any databases;
An issue is the effect of accesses made to an item of persistent data by a non distributed transaction. A local transaction, which involves access to only a single database and/or uses a single server, is a common form of non distributed transaction. Traditionally, the two phase commit protocol is not applied to a non distributed transaction because their does not exist a risk that a first database will be updated with new information from the transaction while a second database will fail to be updated with new information from the transaction. Thus, the traditional approach is to access a database with a two phase commit protocol for distributed transactions but not for non distributed transactions. For non distributed transactions, commands having the effect of a direct “read” or “write” are issued by a resource manager to its corresponding database.
Using a two phase commit protocol for distributed transactions but not for non distributed transactions causes a database to be treated “differently” as between distributed and non distributed transactions. That is, for distributed transactions a database will receive prepare and commit commands while for non distributed transactions a database will not receive a prepare command. It should be understood that a specific item of persistent data may be targeted by both distributed and non distributed transactions alike over the course of its existence.
Various persistent data management inefficiencies may result as a consequence of different access schemes being used for the different types of transactions. Persistent data management typically involves the question of how to handle a situation where at least two different transactions desire control and/or use of a same item of data (sometimes at approximately the same time). For example, if an airline enterprise maintains a database record for a particular flight, multiple customers may be simultaneously attempting to reserve the same seat on the same flight. For distributed transactions, the structure of the two phase commit protocol is often used to support the designed for treatment of competing needs to control and/or use persistent data.
For example, to name just one possibility, a “prepare” command issued for the write of a specific item of persistent data during a distributed transaction could be used to trigger some awareness or alertness to another application (e.g., because the other application is sensitive to changes to the data item). Because non distributed transactions do not invoke the use of a prepare command, no such awareness can be designed for a non distributed write command unless additional functionality is designed to account for awareness without a prepare command being issued. Other issues may arise simply because distributed transactions receive a two-phase commit protocol while non distributed transactions do not.
A solution then is to emulate a two-phase commit protocol for writes made to a database as part of a non distributed transaction. So doing causes a non distributed transaction to be designed, like a distributed transaction, to perform its database read(s) and perform whatever executions/calculations it performs prior to updates that reflect changes in the database's data being written back to the database.
Note that the non distributed transaction of
When the application software 204 associated with the non distributed transaction is complete so as to define any changes that need to be made the database's data (e.g., an update of new information to information that was read 1 from database 202, the addition of new data, etc.), a prepare command is issued to the database 202. The resource manager 203 associates with the prepare command, in a format that is recognizable to the database 202, the write data that corresponds to the change(s) to be made to the database's data. The write data may originate from the cache 205. According to one embodiment, the prepare command 2 that is sent to the database 202 by the resource manager 203 is in response to the resource manager itself receiving a prepare command (or a command that is interpreted by the resource manager 203 to send a prepare command to the database 202).
In one embodiment, a “commit” command is sent 3 to the database by the resource manager 203 before a “ready” response that is sent by the database 202 is received by the database 202. Here, recall that the two-phase commit protocol has been traditionally used to ensure that a distributed transaction can never update a first database and fail to update a second database. But in the case of a single database non distributed transaction (as is the case in the example of
The “commit” command 3 can therefore be issued to the database prior to reception of a “ready” command. If the database 202 happens to issue a “rollback” response to the “prepare” command 2 that it received, the database 202 can be designed to ignore the premature “commit” command 3 that was sent by the server 201 to the database 202. The sending of the “prepare” and “commit” commands 2, 3 to the database 202 even though the transaction is not a distributed transaction makes the distinction between distributed and non distributed transactions transparent to the database 202. Therefore, persistent data management schemes (such as those that trigger awareness of a potential data change on a prepare command) can be applied to database updates where no understanding of transaction type is necessary.
Simulating a two-phase commit protocol for a non distributed transaction as described above corresponds to updating “together” all of the changes to be made to the database's persistent data as a consequence of the application's complete execution being performed. That is, changes to the database's persistent data are not strung-out over the time period of the application's execution; but rather, are made during execution of the coordinated two-phase commit protocol emulation after completion of the application or at least until after all changes to made to the database's persistent data as consequence of the application's complete execution have been confirmed.
Thus, for example, if a change is to be made to a specific item of persistent data (e.g., a database data entry such as a row of data in a database table) early on in the time span of the application's execution, the change is not immediately made in the database but rather is delayed until execution of the simulated two-phase commit protocol after the application's execution is complete. Delaying all persistent data changes resulting from the application's complete execution in this manner causes the database's persistent data to be updated only once as a consequence of the application's complete execution. This, in turn, corresponds to the application making reduced demand upon the database. Reducing the demand upon the database in this manner should result in improved database performance/efficiency.
According to one embodiment, the commit command 3 that is sent to the database 202 by the resource manager 203 is in response to the resource manager itself receiving a commit command (or a command that is interpreted by the resource manager 203 to send a commit command to the database 202). Also, as already described above, the prepare command 2 that is sent to the database 202 by the resource manager 203 is in response to the resource manager itself receiving a prepare command (or a command that is interpreted by the resource manager 203 to send a prepare command to the database 202).
In an object oriented environment, the module 305 of transaction context software may be implemented as a transaction context object. In a further embodiment, the transaction context object includes a data field that indicates whether or not the transaction is a distributed transaction (e.g., a “globalcontext” parameter that, if a null value or non existent, indicates that the transaction is a non distributed transaction; or, if not a null value or is in existence, indicates that the transaction is a distributed transaction).
Depending on perspective and/or design, a non distributed transaction may not be recognized into the conscience of the server 301. For example, according to one perspective, the only recognized “transaction” is what has heretofore been referred to as a “distributed transaction” and what has heretofore been referred to as a “non distributed transaction” is viewed as an isolated thread (where a thread is a single flow of executions). In an embodiment where such a perspective is maintained, a transaction context (and/or transaction context object) exists only if the transaction is what has been heretofore referred to as a “distributed transaction”. If so, a further embodiment entails creating a transaction context even though it references a thread. In other approaches, a transaction context may naturally exist for non distributed transactions (e.g., with a special identifier that registers it as a “null” or “unspecified”) so a specially created context is not necessary.
Irregardless of perspective, a transaction context may be used to identify those database items that need to be written into the database to update or add persistent data as a consequence of the non distributed transaction's execution. As such, the transaction context is used in conjunction with the resource manager 303 to send the write data to the database in view of a corresponding prepare command. In an object oriented environment, the transaction context object 305 would identify specific objects that need to be written into the database.
The transaction context module 305 may also issue prepare and commit commands to the resource manager 303 (or commands that are interpreted by the resource manager 303 to cause the resource manager 303 to send prepare and commit commands 2, 3 to the database 302) in light of the state of the non distributed transaction. For example, in an object oriented environment, a transaction context object for the non distributed transaction may be retrofitted with one or methods that recognize the completion of its corresponding non distributed transaction's tasks; and, in response to this recognition, forward to the resource manager 303 a prepare command or other message that causes the resource manager 303 to send a prepare command to the database.
Likewise, the transaction context object 305 may be similarly retrofitted with one or more methods that send the resource manager a commit command (or a command that causes the resource manager 303 to send a commit command to the database 302). The timing of when a commit is sent to the resource manager may be without regard to the reception of a “ready” command from the database 302 (as discussed at length above with respect to
Note that, in a sense, a transaction context module 305 (such as a transaction context object) that assumes control of the sending of prepare and commit messages as described just above, in a sense, acts as a transaction manager for a non distributed transaction. Recall that the role of a transaction manager for distributed transactions has already been described in the background of the present application. Accordingly, it may be an alternative approach to retrofit a transaction manager with the ability to control the issuance of prepare and commit messages at the end of a non distributed transaction. For example, certain software platforms come with an extensive suite of services/modules (such as a Enterprise Java Beans contained having both transaction manager services (JTA) and resource manager services (JDBC)). The transaction manager service/module of such a suite may be designed to cause prepare and commit messages for non distributed transactions. Alternatively, again if the perspective is enforced that only distributed transactions are recognized transactions, some other entity (such as transaction context object in an object oriented environment as described above) may be used.
Processes taught by the discussion above may be performed with program code such as machine-executable instructions which cause a machine (such as a “virtual machine”, general-purpose processor or special-purpose processor) to perform certain functions. Alternatively, these functions may be performed by specific hardware components that contain hardwired logic for performing the functions, or by any combination of programmed computer components and custom hardware components.
Program code may be stored by a machine-readable medium. The machine-readable medium may include, but is not limited to one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).
It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation).
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
