Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-06-30
2002-08-27
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C709S229000
Reexamination Certificate
active
06442552
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to the field of multiphase transactions. In particular, this invention is drawn to distributed transactional processing.
BACKGROUND OF THE INVENTION
Internet commerce applications are typically distributed applications with at least a three tier architecture. One tier handles presentation (e.g., the user interface), another tier handles the logic of the application, and yet another tier handles the data. Clients (e.g., browser software) handle the presentation. Application servers such as web servers handle the core logic of the application, but are otherwise stateless. A database contains the data and the state of the application. Application servers processes a client submitted request and store a resulting state in the database. The application server then returns a result to the client. This architecture has become prevalent with the advent of commerce on the Internet.
One advantage of partitioning the commerce applications into several tiers is that modularity provides for ease of management and scalability of the applications. Reliability in processing transactions is also needed to ensure that transactions are processed efficiently and with certainty. One disadvantage of the multi-tier architecture is that reliability is limited to “at most once” request processing. Essentially, the request will be serviced at most once, if the request is processed at all.
A limitation of such a reliability standard is that the client-side software may not be able to distinguish between “all” or “nothing”. If a failure occurs at the application server or database tier or a timeout occurs on the client side during processing, the end user receives an exception notification.
The exception notification does not indicate whether the requested transaction was performed or not. The user retries the request at the risk of inadvertently executing the transaction more than once. Thus reliability for each transaction is limited to an “at most once” transaction processing and the client can issue multiple requests to obtain an “at least once” assurance. Unfortunately, rather than an “exactly once” result, the combination of submitting the same request multiple times with an “at most once” reliability standard places the end user at risk of having the desired request being processed more than once.
Client transparency masks middle tier and database failures from the front-end client. One goal of client transparency is to ensure “exactly once” processing by automatically retrying transactions at the appropriate server level when the transactions abort due to failures at the server or database tiers.
One technique for client transparency relies on the assurance that a single server handles a selected request. This may not be a practical approach in an environment where multiple application servers may be concurrently working on the same request. Additional transaction tracking overhead is required in fault tolerant system to ensure that the primary server(s) handling a transaction have indeed failed, thus delaying the backup server take-over process. The failure detection process must be perfect in order to ensure that only one of the primary or the backup server is handling the request. Delaying the backup server take-over may result in a substantially increase in the number of potentially at-risk transactions due to the asynchronous nature of the requests.
One three tier architecture uses a transaction processing monitor to enable clients to abort a transaction if a reply value is not received from the second or third tiers after a pre-determined time interval. The client, however, does not participate in the commitment of transactions. If the second or third tier transaction manager fails, the outcome of the transaction may be unknown to the client.
Another solution is to include the client as a participant in order to ensure the outcome is communicated to the client. One disadvantage of this approach is that “thin clients” such as browsers may not have the resources needed to support participation. Furthermore, additional communication is required between the client and the second tier because the client will be involved in the two-phase commit process. Finally, as a participant, the client becomes a potential point of failure for the two-phase commit process required across the transaction participants.
SUMMARY OF THE INVENTION
Methods and apparatus for performing three tier asynchronous client transparency are described. A method for processing at the client tier includes the step of sending a request and a count from a client to a first application server of an application server group. The request and count are resent to the application server group, if no corresponding decision comprising a result and an outcome is received within pre-determined time period. The request is resent with an incremented count to a selected one of the first application server and the application server group, if a corresponding decision comprising a result and an outcome indicates that the result has not been committed. The result of the decision is provided to an end-user, if the outcome indicates that the result has been committed.
A method for processing at the application tier includes the step of receiving a request originating from a client tier. An attempt to write a first application server identifier to a write-once register entry associated with the request is made in response to receipt of the request by the first application server. A result is computed for the request. An outcome is determined for the result. An attempt to write the result and outcome as a first decision to the write-once register entry is performed. An attempt to terminate a transaction identified by the write-once register entry in accordance with a second decision indicated by the write-once register entry is then performed.
A method of handling transactions for application servers suspected of failure includes the step of selecting an active transaction of a suspected application server of an application server tier. An attempt is made to invalidate the transaction by writing a decision with an aborted first outcome to a write-once register entry associated with the selected active transaction. Commands are issued to a database tier to terminate the transaction in accordance with a second outcome indicated by the write-once register entry.
Other features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows below.
REFERENCES:
patent: 6085198 (2000-07-01), Skinner et al.
patent: 6134594 (2000-10-01), Helland et al.
patent: 6226637 (2001-05-01), Carey et al.
patent: 6266666 (2001-07-01), Ireland et al.
patent: 6285997 (2001-09-01), Carey et al.
Frolund Svend
Guerraoui Rachid
LandOfFree
Method and apparatus for implementing three tier client... 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 and apparatus for implementing three tier client..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for implementing three tier client... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2905907