Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-11-02
2001-10-23
Beausoleil, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S020000, C707S793000
Reexamination Certificate
active
06308287
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to the field of transaction processing for data processing systems, and particularly to the processing of applications comprising multiple component transactions.
BACKGROUND OF THE INVENTION
In the field of transaction processing, transactions are generally required to have what are known as the ACID properties. ACID is an acronym representing the four transaction properties of: Atomicity, Consistency, Isolation and Durability. Atomicity requires that all the operations of the transaction must occur or none must occur. Consistency requires a transaction to maintain the consistency of the database. Isolation requires a transaction not to read the intermediate results of another transaction. Durability requires the results of a committed transaction to be made permanent. For background information on the ACID properties, see
Transaction Processing: Concepts and Techniques
, J. Gray and A. Reuter, which is hereby incorporated by reference.
Large enterprise applications implemented using an Online Transaction Processing (OLTP) system will typically use a number of individual ACID transactions to implement a function that the business regards as a complex, but coherent update to business data. It is not possible simply to implement the business transaction as a single ACID transaction because of data and resource sharing requirements in the OLTP environment.
This mismatch between the transaction processing system's notion of a transaction and that of the business analyst has become greater as applications have grown more and more complex. It has forced on the application developer additional complexity to coordinate a collection of transactions so that they behave as required by the business analyst.
Coordination of transactions is mainly handled by the ingenuity of the application designer using the standard Application Programming Interface (API) of the transaction processing system. The application will need to maintain some state data to record progress through the collection of transactions, and each individual transaction will need a means to provoke the next and so make progress. This provocation is a form of signaling.
Application progress state data can be managed in a number of ways. For example, it can be made recoverable by storing it in the database chosen for the application. It is good practice to isolate this ‘working storage’ of the application from the enterprise data with a longer lifetime (e.g. customer records).
Where the progress through the application is primarily driven by end user actions, the series of transactions may be termed a ‘pseudo-conversation’. Input from the end user's terminal is taken as the signal for the next transaction to be initiated. Normally, some state data is passed to the newly-initiated transaction. In a well-known transaction processing system, IBM's CICS (CICS is a registered trademark of International Business Machines Corporation), the state data is simply a piece of virtual storage associated with the user's terminal (‘pseudo-conversational COMMAREA’).
The facilities available to the application to programmatically signal progress through the series of transactions can be very limited and the ACID properties of each of the transactions are inhibitors because of the need for business applications comprising multiple component transactions to continue to progress even if one of the component transactions fails; this is because the Isolation property means that all the effects of the failing transaction must be reversed, or “backed out”.
Typically, a transaction processing system's API includes a command to cause the execution of another transaction, and one way in which application programmers have tried to overcome the above limitations is by use of this START command. In the CICS API there is the START command. The START command allows an application program executing in one transaction to cause another transaction to be created and begin execution. The command creates a request to run a transaction; this request is called an ICE (Interval Control Element). Data may be passed from the originating transaction to the new one. The START command allows a PROTECT parameter that is used to specify the recovery characteristics of the effect of the command.
A protected START has ACID properties: its effects are only committed during a successful forwards commit of the transaction that issued it; the ICE and the data to be passed to the new transaction are stored in a recoverable resource. The result of a committed, protected START request is guaranteed to happen, and happen only once. An unprotected START does not obey ACID transactional semantics. The new transaction is created and begins execution immediately, potentially in parallel with the originating transaction. The ICE and the data are not stored in a recoverable resource. There are no guarantees that the result of an unprotected START command happen, nor that they only happen once.
Use of the START command to provoke progress through the application has limitations. Application programmers have attempted to circumvent these limitations, but this is extremely difficult and unreliable. Using unprotected START commands does not give the level of assurance normally associated with a transactional application. For example, an unprotected START might be used to provoke the next step in an application, but the originating transaction then terminates abnormally and backs out its recoverable updates. The transaction resulting from the unprotected start then has to determine the state of the application, taking into account the fact that some previous step failed. A system restart will lose any pending unprotected START requests, and so lose the thread in the application. Using protected START commands ensures that the progress is in step with the success of the transactions and behaves reasonably across system failures. But the very ACID properties that give these characteristics lead to a different problem that application programmers have to overcome. A protected START results in nothing if the originating transaction performs backout (e.g. in the event of application failure). So it is not possible for an abnormally terminating transaction to actively cause the continuation of the application.
Application programmers may attempt to cope with this case by creating a delayed START request as a ‘back-stop’ to detect the failure of a particular step. In the case that the transaction commits, the backstop request is redundant and discarded, whereas in the backout case the time interval elapses and the backstop transaction executes—implying that a backout occurred previously. The limitations of this technique are that it increases the complexity of the application progress management, it is not fully reliable over system failure, it is extremely difficult to program since the backstop transaction needs to cope with the varying times it might be executed and whether or not the main transaction has succeeded, and finally the choice of the delay time for the backstop transaction is difficult and limits application progress rate.
In the past, various transaction processing models have been proposed, including models for long-running, extended transactions having nested subtransactions. One model which attempts to deal with the problems of multiple-step transactional applications is the ConTract model, described by Waechter and Reuter in their paper “The ConTract Model”, in
Database Transaction Models for Advanced Applications
, edited by A. K. Elmagarmid, which is here incorporated by reference. The ConTract model provides a theoretical framework for business transactions involving the use of sets of flow control and dependency relations between steps under the control of a ConTract managing entity. The paper explicitly states that: “A special kind of global, nested transactions is necessary for structuring the system's work during processing ConTracts”. A hierarchical structure of this sort has the disadvantage of
Mitchell Ian James
Powell Steven
Baderman Scott T.
Beausoleil Robert
Herzberg Louis P.
International Business Machines - Corporation
LandOfFree
Transaction processing system, method and computer program... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transaction processing system, method and computer program..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transaction processing system, method and computer program... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2598991