Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Protection at a particular protocol layer
Reexamination Certificate
2000-07-12
2002-12-10
Wright, Norman M. (Department: 2131)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Protection at a particular protocol layer
C713S178000, C714S016000
Reexamination Certificate
active
06493826
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to fault tolerant transaction-oriented data processing, and in particular to an efficient method and system for supporting recoverable resource updates within transactions such as in a transaction-oriented messaging system, file system or database system.
2. Description of the Related Art
Many business functions can be implemented by transaction processing using application-oriented computer programs. Most application-oriented programs need to access some form of computer system facilities (facilities such as processors, databases, files,input/output devices, other application programs) - which are generically known as resources. The system software which controls these resources is generically known as the resource manager. A common processing requirement is to be able to make a coordinated set of changes to one or more resources (and in particular to collections of data objects), such that either all of the changes take effect, and the resources are moved to a new consistent state, or none of them does. This property of all-or-none processing is known as “atomcity”.
As pointed out by C. J.Date in “An Introduction to Data Base Systems”, Vol. 1, 4th Edition, Addison-Wesley Publishing Co., 1986, Ch.18, a “transaction” is a logical unit of work referencing a sequence of associated operations that transforms a consistent state of one or more recoverable resources into another consistent state (without necessarily preserving consistency at all intermediate points). Transaction processing is the management of discrete units of work that access and update shared data.
It is known to provide fault-tolerant transaction processing systems which can maintain data consistency and transaction atomicity over system, media and transaction failures (an example of the latter being application detected error conditions leading to the inability of a transaction to complete). To enable recovery of resources to a consistent state following a failure, it is necessary for the system to keep a record of the state of system resources at the time of the failure, which includes knowing which transactions had been completed, to enable the completed transactions to be performed again, and which transactions were in progress to enable the operations within an uncompleted transaction to be undone. A transaction thus defines a unit of recovery as well as a unit of work.
It is frequently a processing requirement for resource updates to be made within a transaction without the delay of verifying, prior to making updates, whether the transaction can complete successfully. For atomicity and consistency in such systems, it is thus necessary to provide a backward recovery facility for when transactions fail to complete successfully—enabling all changes that have been made to resources during the partial execution to be removed.
The restoration of resources to the consistent state which existed before a transaction began is known as ROLLBACK (or synonymously as BACKOUT; a total ROLLBACK of a transaction being known as an ABORT) of the transaction, the changes generally being removed in the reverse chronological order from which they were originally made.
One example of a system which may employ transactional techniques is a messaging and queuing system described in the document “IBM Messaging and Queuing Series—technical Reference” (SC33-0850-01, 1993). Messaging and queuing provides a number of facilities for high-level interprogram communication. It encompasses:
Messaging—a simple means of program-to-program communication that hides communication protocols.
Queuing—the deferred delivery of messages. This enables asynchronous communication between processes that may not be simultaneously active, or for which no data link is active. The messaging and queuing service can guarantee subsequent delivery to the target application.
Message driven processing—the accomplishment of an application task by the flow of messages to a number of processes in distributed system. The processes work together by accessing queued messages and generating new messages until the application task is completed.
Most applications need to access resources of one form or another, and a common requirement is to be able to make a coordinated set of changes to two or more resources. “Co-ordinated” means that either all of the changes made to the resources take effect, or none of them does.
Queues are no exception to this—applications need to be able to get and put messages (and possibly update other resources, such as databases), and know that either all of the operations take effect, or that none of them does. The set of operations involved in this is called a transaction or unit of work. The following example illustrates this:
In a financial application that transfers funds from one account to another at the same location, there are two basic operations that need to be carried out: the debit of one account, and the credit of the other. Normally both of the operations succeed, but if one fails, both must fail.
The failure might be for operational reasons (for example, one queue being temporarily unavailable), in which case the transaction can be presented again later. Alternatively, the failure might be because there are insufficient funds in the account to be debited, in which case a suitable response must be returned to the initiator of the transaction.
The debiting of one account and the crediting of the other constitute a unit of work.
A unit of work starts when the first recoverable resource is affected. For message queuing, this means when a message is got or put as part of a unit of work. The unit of work ends either when the application ends, or when the application declares a syncpoint (see below.) If the work is ended by the application declaring a syncpoint, another unit of work can then start, so that one instance of an application can be involved with several sequential units of work.
Each get or put operation can separately participate in the current unit of work. The application chooses which operations participate by specifying the appropriate “syncpoint” or “no-syncpoint” option on MQGET, MQPUT and MQPUT1 calls. If neither option is specified, participation of the call within the current unit of work is determined by the environment.
The application ends a unit of work by declaring a syncpoint. When a syncpoint is declared, any party that has an interest in the unit of work can vote “no” and so cause the unit of work to be backed out; this has the effect of undoing all of the changes that were made as part of the unit of work. If all parties vote “yes”, the unit of work is committed, and the changes that were made as part of the unit of work become permanent. Parties interest in the unit of work can be:
The application
The queue manager
Other resource managers
The application declares a syncpoint, and registers its vote, by issuing the appropriate environment-dependent call.
If a message is put as part of a unit of work, the message does not become generally available for retrieval by applications until that unit of work is committed successfully. The one exception to this is the application which put the message. It can retrieve the message from the destination queue as part of the original unit of work before that unit of work is committed; the destination queue must be a local queue for this to be possible.
If the destination queue belongs to a remote queue manager, the message is not available to be sent from the local queue manager until the unit of work is committed. This means that it is not possible to send a request message and receive the reply to that request as part of the same unit of work; the unit of work containing the request message must be committed before it is possible to receive the reply.
Any errors detected by the queue manager when the message is put are returned to the application immediately by means of the completion code and reason code parameters. Errors that can be detected in this way include:
Message too big for queue
Schofield Andrew John
Washer Anthony Robert
Bracewell & Patterson L.L.P.
Duffield Edward H.
International Business Machines - Corporation
Wright Norman M.
LandOfFree
Method and system for fault tolerant transaction-oriented... 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 system for fault tolerant transaction-oriented..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for fault tolerant transaction-oriented... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2970026