Source: http://www.google.com/patents/US6389431?dq=6,304,975
Timestamp: 2014-09-17 13:48:36
Document Index: 451628895

Matched Legal Cases: ['art� 34', 'art� 34', 'art� 34', 'art� 34', 'art� 34', 'art� 34']

Patent US6389431 - Message-efficient client transparency system and method therefor - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA three-tier system is built up as: a single client application, a single server application, and a single database system. The server application provides a service that can be shared among multiple client applications. Server applications store their data in a database system. A client transparency...http://www.google.com/patents/US6389431?utm_source=gb-gplus-sharePatent US6389431 - Message-efficient client transparency system and method thereforAdvanced Patent SearchPublication numberUS6389431 B1Publication typeGrantApplication numberUS 09/383,107Publication dateMay 14, 2002Filing dateAug 25, 1999Priority dateAug 25, 1999Fee statusPaidPublication number09383107, 383107, US 6389431 B1, US 6389431B1, US-B1-6389431, US6389431 B1, US6389431B1InventorsSvend Frolund, Rachid GuerraouiOriginal AssigneeHewlett-Packard CompanyExport CitationBiBTeX, EndNote, RefManPatent Citations (6), Non-Patent Citations (3), Referenced by (10), Classifications (12), Legal Events (6) External Links: USPTO, USPTO Assignment, EspacenetMessage-efficient client transparency system and method thereforUS 6389431 B1Abstract A three-tier system is built up as: a single client application, a single server application, and a single database system. The server application provides a service that can be shared among multiple client applications. Server applications store their data in a database system. A client transparency mechanism and a server transparency mechanism are added. A database system on a clustered node is used for the database management. Server applications implement transactional behavior and the server side of the protocol so that the client applications may recover from server application and database system failures. The cluster application programming interface is used to determine when to retry. Information is stored in the database system so that the outcome of the transaction can be determined.
CROSS-REFERENCE TO RELATED APPLICATION(S) The present application contains subject matter related to a concurrently filed U.S. Patent application by Svend Frolund and Rachid Guerraoui entitled �MULTIPLE DATABASE CLIENT TRANSPARENCY SYSTEM AND METHOD THEREFOR� and identified by application Ser. No. 09/382,557.
The present application further contains subject matter related to a co-pending U.S. Patent application by Jayaram R. Kasi, Jari Koistinen, Ellis Chi, and Svend Frolund entitled �CLIENT TRANSPARENCY SYSTEM AND METHOD THEREFOR� which was filed Dec. 15, 1998, and is identified by Ser. No. 09/212,739.
TECHNICAL FIELD The present invention relates generally to transaction processing systems (TPS) and more particularly to recovery from failures during transaction processing which minimizes user intervention.
BACKGROUND ART Commonly, human end-users are exposed to many different failures and error situations in systems which are called transaction processing systems (TPS). TPSs are three-tier (client-server-database) systems which allow client applications to perform database transactions. For example, there are various reservation systems, such as for airlines, hotels, and car rentals, and financial systems, such as banking, credit card, and automated teller machines. In these systems, a customer or sales representative uses a client application that allows a user to query and update a database. The client interface allows the client to specify which database to add information to or to update. If a failure occurs, for example during an update, it is difficult for the client to know whether the update was actually performed or not.
Traditional, high availability solutions for database-centric applications are typically based on clusters. A cluster consists of multiple computers, called nodes. Each node is capable of running a database, and when the database fails, it is restarted by cluster manager software. The consistency model for the database is based on the notion of �rollback� where the database is restarted in some previous, consistent state. The transactions that were being executed when the database failed are aborted.
DISCLOSURE OF THE INVENTION The present invention is targeted to three-tier transaction processing systems (TPSs) built up as: a single client application (CA), a single server application (SA), and a single database system (DBS). The client application implements an application that requires data and services that are best realized as distributed resources. A SA represents such a resource. The SA provides a service that can be shared among multiple CAs. SAs store their data in a database. A client transparency mechanism (CTM) and a server transparency mechanism (STM) are added, and both can be represented as conventional state machines. A database on a clustered node is used for the database management. SAs implement transactional behavior. The STM implements the server side of the protocol so that the CAs may recover from SA and database failures. The cluster application programming interface (API) is used to determine when to retry. Information is stored in the database so that the outcome of the transaction can be determined.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a three-tier TPS incorporating the client transparency system of the present invention;
BEST MODE FOR CARRYING OUT THE INVENTION Referring now to FIG. 1, therein is shown a transaction processing system (TPS) 10. A user 11 of the TPS 10 would interact with a client application (CA) 12, which could be one personal computer in a large network. The CA 12 has an attached client transparency mechanism (CTM) 14. The CTM 14 is connected to a conventional communications infrastructure (CI) 16.
Referring now to FIG. 2, therein is shown the basic structure of the method of the present invention which is depicted as a �timeline diagram� 30. The �timeline diagram� 30 shows the order in which components of the TPS 10 exchange messages across the CI 16. The vertical lines represent the system components, which are the CA 12, the CTM 14, the STM 18, the SA 20, and the DBS 22. The user 11 is shown with the CA 12. Horizontal lines represent messages. A line with one arrow represents a single message with the arrow indicating the direction of the message from the sender to the receiver. A line with two arrows represents bidirectional messaging. The lines with two arrows allow for abstraction of the exchange of multiple messages as one logical exchange.
The user 11 first inputs a transaction into the CA 12. The CA 12 generates a universally unique identifier (UUID) for the transaction and then sends a transactional �request� 32, which contains the UUID and information for the transaction, to the CTM 14. The CTM 14 resends it to the STM 18. The STM 18 then sends a �start� 34 message to the DBS 22 to start a transaction. After the �start� 34, the STM 18 sends the �request� 32 to the SA 20. In response to the �request� 32, the SA 20 implements a �read/write� 36 with the DBS 22 and manipulates the DBS 22 in an application-specific manner. For example, the application-specific manner could be a banking transaction such as a deposit, withdrawal, transfer between accounts, etc.
When the manipulation is complete, the STM 18 sends an �insert UUID/result� 38 command to the DBS 22 which appends the UUID for the transaction and a corresponding result of the transaction to a storage area within the DBS 22. After the �insert UUID/result� 38 command, the STM 18 sends an �end� 44 to the DBS 22 which indicates to the DBS 22 that manipulations are complete. The STM 18 then sends a �commit� 50 command to the DBS 22 and a �committed� 52 message to the CTM 14 as the response to the �request� 32. The CTM 14 then provides a �reply� 54 message to the CA 12 to indicate completion of the transaction. The �reply� 54 message contains the result of the �request� 32. For example, the �request� 32 is a deposit to a checking account and the �reply� 54 containing the result is the balance in the checking account after the deposit.
The �commit� 50 command memorializes the completed manipulation to the DBS 22. Until the completed manipulation is committed, it is transient and can be rolled back. The DBS 22 saves the UUID and the corresponding result of the manipulation for later recall to handle failures, or undesirable conditions, that happen during a server-side commit operation. If the CA 12 observes such failures, it does not know, per se, if the transaction was committed before the failure happened. If the transaction was not committed, the CA 12 must retry the transactional request. However, if the transaction was committed, the CA 12 must not retry the transactional request; otherwise, the transaction would be duplicated. The STM 18 sends the UUID and inserts it and the result corresponding to that UUID into the DBS 22 as part of the server-side transaction. The CTM 14 can then use this UUID as a handle to the transaction and determine if the transaction has been committed. Since the UUID insertion is part of the transaction, the UUID will be in the database if and only if the transaction has been successfully committed. The STM 18 transmits the �commit� 50 command before it provides the �committed� 52 message to the CTM 14.
As can be seen from the above, the method has a single-phase nature. One logical method invocation involves one actual application of the STM 18 and DBS 22 messages. The initial invocation executes the transaction and commits it as a completed transaction in the DBS 22. The single-phase nature alleviates message congestion between the CTM 14 and the STM 18 and reduces delays in processing the transaction by not having to wait for the CTM 14 to respond. Accordingly, the CTM 14 submits a single invocation and waits for the �committed� 52 message that contains the result of the �request� 32 from the STM 18. If the CTM 14 does not receive the �committed� 52 message, it needs to retry the method invocation. The CTM 14 should not perform the retry if the transaction has already been committed at the server side since that would cause the transaction to be executed twice.
Referring now to FIG. 3, therein is shown the operation of the method of the present invention when there is a failure, or undesirable operational condition, during the �request� 32. The method of operation is depicted as a �timeline diagram� 60. It should be noted that the present invention is described by its functionality in handling a couple of representative failure scenarios. It would be obvious to those having ordinary skill in the art to understand how the system and method operate without undue experimentation.
Thus, FIG. 3 illustrates the method of operation when a SA 20-1 fails part way through a transaction during the �request� 32. As well known to those skilled in the art, server applications have various means of indicating when they have failed. These means include the application of a hearbeat, pinging, or timeout.
The user 11/CA 12/CTM 14 send the �request� 32 through the STM 18-1 to SA 20-1, and the STM 18-1 sends �start� 34 to the DBS 22. If a failure occurs at the SA 20-1 before the transaction has completed, the CTM 14 recognizes a �failure� 64 which causes the CTM 14 to retry the method invocation. The �failure� 64 causes the server process to terminate, and the CTM 14 cannot retry the method invocation against the same server application SA 20-1. The CTM 14 needs to retry against a different server.
After the user 11/CA 12/CTM 14 send out the initial �request� 32 to the STM 18-1, the STM 18-1 and DBS 22 begin communication with a �start� 34.
With a failure in SA 20-1 sometime after the �start� 34, CTM 14 determines that the �failure� 64 has occurred in the STM 18-1. The CTM 14 then sends a �get server� 66 message to the LBS 26 which selects a server application that is available and has the same functionality, such as SA 20-2, with �reference to SA 20-2� 67. The CTM 14, without the intervention of the user 11, then sends a message, �retry� 68, to the STM 18-2. The �retry� 68 message is similar to the original �request� 32 and includes the UUID of the original �request� 32 which failed before completion. In response, the STM 18-2 sends a �rollback� 70 to the DBS 22 in order to free up resources, such as database locks, held by the failed transaction. When the rollback is complete, the DBS 22 is rolled back to the last committed transaction, and sends an acknowledgement message, �ack� 72, back to the STM 18-2.
With the receipt of the �ack� 72, the CTM 14 proceeds with a request, �lookup UUID� 74, to the DBS 22. The DBS 22 proceeds to retrieve a UUID and a result corresponding to the �request� 32. In this case, the DBS 22 has not committed to the transaction for the �request� 32 and the UUID and the result is not found. Accordingly, the DBS 22 sends a �not found� 76 to the STM 18-2. The STM 18-2 in turn sends a �not found� 78 to the CTM 14 and resends the �request� 32 to SA 20-2 and, without failures, will proceed with the same transaction, which is the same as shown in FIG. 2 and which utilizes the same messages with the same numbers as shown therein.
In the alternative situation in which the DBS 22 matches the UUID with a corresponding result, the DBS 22 returns the result to the STM 18-2 and CTM 14. The CTM 14 sends the result in �reply� 54 to the user 11/CA 12 in response to the �request� 32. Thus, the user 11/CA 12 receives a result in response to the �request� 32 and is unaware of failures within the TPS 10. The user 11 and the CA 12 are not involved in the recovery from the failure of the SA, so the failure recovery is transparent to them.
Referring now to FIG. 4, therein is shown the method of the present invention when there is a failure during the commit phase when it is not possible to determine when a server failed. The �timeline diagram� 80 shows the user 11/CA 12/CTM 14 providing the �request� 32 to the STM 18-1. After a �start� 34 from the STM 18-1 to the DBS 22, the STM 18-1 causes the SA 20-1 to execute the �request� 32 with �read/write� 36 operation and sends an �insert UUID/result� 38 followed by an �end� 44, and a �commit� 50 to the DBS 22, but the SA 20-1 fails while committing the transaction.
The CTM 14 recognizes the �failure� 82, and can not determine if the transaction was actually committed in the DBS 22 because the CTM 14 cannot tell exactly when the SA 20-1 failed.
To determine the outcome of the transaction, the CTM 14 first obtains a new server, SA 20-2, from the LBS 26 using the �get server� 84 and obtaining the �reference to SA 20-2� 85. The CTM 14 then sends a message, �retry� 86, to the STM 18-2 for it to determine if the transaction is in the DBS 22. The �retry� 86 includes the UUID of the in-progress transaction when the failure occurred. The STM 18-2 sends a �rollback� 88 command to the DBS 22 to ensure that some other server application has not already started the transaction against the DBS 22. Once the DBS 22 has successfully rolled back, it sends a �done� 89 message to the STM 18-2. Upon receipt of the �done� 89 message, the STM 18-2 sends a �lookup UUID� 90 command to the DBS 22 to determine if the transaction was committed. For example, where the transaction did not commit, the DBS 22 will return a not found message in which case the STM 18-2 sends the �request� 32 to the SA 20-2 to process the transaction.
Assuming that the failure occurred after the �commit� 50 was executed, the DBS 22 matches the UUID and retrieves a �result� 92 of the transaction corresponding to that UUID and sends the �result� 92 to the STM 18-2 which resends it to the CTM 14. The CTM 14 sends the result in �reply� 54 to the user 11/CA 12 in response to the �request� 32. Thus, the user 11/CA 12 receives a �reply� 54 having a result that is responsive to the �request� 32 and is unaware of failures within the TPS 10. The user 11 and the CA 12 are not involved in the recovery from the failure of the SA, so the failure recovery is transparent to them.
The �rollback� 86 command prevents multiple servers from executing the same transaction at the same time. This prevents duplicity of transactions which may occur during failure recovery of the TPS 10 from an undesirable operational condition.
If there is a failure of the SA 20-1 as shown by the �X�, the SA 20-1/STM 18-1 informs the CTM 14 by the arrow 122. The CTM 14 will then fetch a reference from the LBS 26 to STM 18-2/SA 20-2. The CTM 14 then invokes the SA 20-2 through the STM 18-2. The STM 18-2 handles the database connections and performs transaction demarcation, while the SA 20-2 directly performs the actual manipulation of the database. The manipulation can be performed in a number of different languages such as Standard Query Language, SQL.
In the event of a failure of the DBS 22 as shown by the �X�, the DBS 22 will provide an indication of its failure by one of a number of mechanisms, which are well known to those skilled in the art, back to the STM 18-2 as shown by the arrow 126. The DBS 22 will also restart itself, or rollback, to its last committed transaction. After the DBS 22 is restarted, the STM 18-2 will cause the communication to be established with the DBS 22 by the arrow 128.
After fetching the initial reference from the LBS 26, the CTM 14 uses this reference until it becomes invalid. In particular, the CTM 14 only communicates with the LBS initially and after failures, as indicated by the arrow 120. If there is a failure of the LBS 26 as shown by the �X�, the references will be maintained in the LBS 26 and the CTM 14 will retry after the LBS 26 is restarted. There will be a failure over to the LBS 26, which then begins to supply references in the event of other component failures.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5721909 *Nov 7, 1996Feb 24, 1998Siemens Stromberg-CarlsonDistributed database architecture and distributed database management system for open network evolutionUS6047323 *Jun 27, 1996Apr 4, 2000Hewlett-Packard CompanyCreation and migration of distributed streams in clusters of networked computersUS6076108 *Mar 6, 1998Jun 13, 2000I2 Technologies, Inc.System and method for maintaining a state for a user session using a web system having a global session serverUS6085220 *Sep 28, 1998Jul 4, 2000I2 Technologies, Inc.Enterprise interaction hub for managing an enterprise web systemUS6115744 *Jul 30, 1996Sep 5, 2000Bea Systems, Inc.Client object API and gateway to enable OLTP via the internetUS6256641 *Dec 15, 1998Jul 3, 2001Hewlett-Packard CompanyClient transparency system and method therefor* Cited by examinerNon-Patent CitationsReference1 *Kantikar et al., Jul. 28-31, 1998, "Two-stage trasaction processing in client-server DBMSs", University of Brooklyn, NY, pp. 98-105.*2 *Pelikan et al., Mar. 1998, "Experience with PACS in an ATM/Etherne switched network environment", Germany, pp. 26-29.3 *S. Englert, Feb. 25-Mar. 1, 1991, "Load Balancing Batch and Interactive Queries in a High Parallel Environment", Tandem Computer Inc, pp. 110-112.** Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6665672 *Oct 30, 1998Dec 16, 2003Xerox CorporationTransaction/object accounting method and systemUS6681225 *May 31, 2000Jan 20, 2004International Business Machines CorporationMethod, system and program products for concurrent write access to a global data repositoryUS7444334 *Sep 11, 2000Oct 28, 2008Foundation Ip, LlcTransaction-based object-oriented multipart database method and apparatusUS7937493Jun 27, 2005May 3, 2011Oracle International CorporationConnection pool use of runtime load balancing service performance advisoriesUS7953860 *Aug 12, 2004May 31, 2011Oracle International CorporationFast reorganization of connections in response to an event in a clustered computing systemUS8108451Feb 2, 2009Jan 31, 2012International Business Machines CorporationSystem and program products for efficiently locking resources of a global data repositoryUS8271636 *Sep 10, 2009Sep 18, 2012Juniper Networks, Inc.Rule-based networking deviceUS8478838May 21, 2010Jul 2, 2013International Business Machines CorporationSystem and method for using a same program on a local system and a remote systemUS8626890Nov 3, 2010Jan 7, 2014Oracle International CorporationConnection pool use of runtime load balancing service performance advisoriesUS8713186Mar 12, 2008Apr 29, 2014Oracle International CorporationServer-side connection resource pooling* Cited by examinerClassifications U.S. Classification1/1, 709/227, 707/999.202, 707/999.201, 707/999.002International ClassificationG06F9/00, G06F9/46Cooperative ClassificationY10S707/99952, Y10S707/99932, Y10S707/99953, G06F9/466European ClassificationG06F9/46TLegal EventsDateCodeEventDescriptionNov 14, 2013FPAYFee paymentYear of fee payment: 12Feb 6, 2012ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;HEWLETT-PACKARD COMPANY;REEL/FRAME:027661/0258Owner name: GOOGLE INC., CALIFORNIAEffective date: 20111025Sep 22, 2011ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:026945/0699Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXASEffective date: 20030131Nov 16, 2009FPAYFee paymentYear of fee payment: 8Nov 14, 2005FPAYFee paymentYear of fee payment: 4Oct 1, 1999ASAssignmentOwner name: HEWLETT-PACKARD COMPANY, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FROLUND, SVEND;GUERRAOUI, RACHID;REEL/FRAME:010277/0586Effective date: 19990825Owner name: HEWLETT-PACKARD COMPANY LEGAL DEPARTMENT, M/S 20BNRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google