WO1993018454A1

WO1993018454A1 - Distributed transaction processing system

Info

Publication number: WO1993018454A1
Application number: PCT/GB1992/001218
Authority: WO
Inventors: Susan Malaika; Michael John Brady; Geoffrey Meacock
Original assignee: International Business Machines Corporation
Priority date: 1992-03-02
Filing date: 1992-07-06
Publication date: 1993-09-16
Also published as: EP0582681A1; GB2264796A; GB9204440D0

Abstract

A method and system for distributed transaction processing between first and second transaction processing means in communication with each other employs a client program on the first transaction processing means which calls a server program on the second transaction processing means. A first type of server program call permits only the first transaction processing means to commit resources for both client and server, both programs effectively being part of a single transaction. A second type of program call permits the second transaction processing means to commit resources independently so that the server program runs as part of a separate transaction.

Description

DISTRIBUTED TRANSACTION PROCESSING SYSTEM

Field of the Invention

The present invention relates to a method of and a system for distributed transaction processing.

Background of the Invention

On-line transaction processing (OLTP) relates to the real time processing of business and commercial transactions such as room or seat reservation and financial transactions. An OLTP system typically supports a network of thousands of terminals and provides near instant access to data held in data sets or databases. To do this it must support the data-communication links between terminals, processors and data.

One very well known family of OLTPs is the IBM Customer Information Control System (CICS) which is described in the publication CICS General Information (GC33-0155-4) , 5th Edition, October 1990, from IBM Corporation. CICS is an application enabling program which runs on a general purpose operating system and provides a common transaction processing support environment to customer application programs via an Application Program Interface (API).

A transaction, in more detail, is a piece of processing initiated by a single request usually from a terminal. A single transaction consists of one or more application programs, that when run, will carry out the processing needed. A transaction is also referred to as a logical unit of work (LUW) in CICS and is also said to be "atomic" in the sense that it may only fail or complete its task, but not partly complete it.

A transaction operates on resources (or entities) which, in the case of CICS, can be keyed and direct access files, sequential files and queues. Transactions can only have one of two outcomes: "committed" or "aborted". If aborted, certain "protected" actions must be redone or undone if irretrievable damage to customer data or propagation of errors is to be avoided.

In either event, the transaction and the recoverable resources it was acting on must be backed up to the state they were in before the transaction started. Transactions are delimited in practice by commit points (or SYNCPOINTS) at which changes to resources are committed so that the resources are restored to their state at the previous SYNCPOINT.

In order to achieve this, it is normal practice in CICS and other OLTP systems to provide Redo and Undo logs of the actions taken since the last SYNCPOINT and also to lock all or selected portions of resources for the duration of a transaction. Further background on transaction processing can be found in a paper by J N Gray ("A Transaction Model", Technical Report RJ2895, IBM Corp. 1980).

Another aspect of known transaction processing systems such as CICS, is the distribution and sharing of function, resources and processing between physically separate systems on different levels, which requires intersystem communication (ISC), or between different CICS regions on the same level, known as multi-region operation (MRO).

Briefly, there are several mechanisms for such intercommunication in CICS:

"Transaction routing" enables a terminal in one CICS system to run a transaction in another CICS system;

"Function shipping" enables an application program to access resources in another CICS system;

"Asynchronous processing" enables a CICS transaction to initiate a transaction in a remote system and to pass data to it;

"Distributed transaction processing" (DTP) enables a CICS transaction to communicate with a transaction in another CICS system; and "Distributed Program Link" (DPL) is a type of function shipping which enables an application program (the client) on one CICS region or system to link to another application program (the server) running in another CICS region or system. The Distributed Program Link was introduced in the CICS OS/2 system (Ref. CICS OS/2 System and Application Guide - SC33-0616, IBM Corp. 1991).

CICS may also communicate with external shared databases and the CICS/ESA 3.2 system handled such communication through a Resource Manager Interface (RMI). Great care is needed to ensure that the integrity of shared data is preserved and, for that reason, a so-called two-phase commit protocol is employed to prevent inconsistent and uncontrolled changes of the database by multiple data or transaction processing systems. (Ref. CICS Task Related User Exits: An implementation for co-ordinating database commits, GG22-0497, IBM Corp. 1991). A certain amount of time is required for completion of the two-phase commit protocol and this, to some extent, reduces the performance of the system.

Proposals have also been made in the prior art for various forms of interrelated transactions which may be useful in a distributed computing environment. So-called nested transactions are described in "Nested Transactions - An Approach to Reliable Distributed Computing" (J E B Moss, MIT Press, 1985). Both portions of a nested transaction in fact run as a single unit of work and incur performance overheads.

The book "Camelot and Avalon - A Distributed Transaction Facility" (Ed Eppinger et al, Morgan Kaufmann Publishers Inc. 1991) also describes nested top-level transactions running on the same system, as opposed to remotely. The same book also describes wrapped server calls in which servers are called by programs that do not run within the scope of a transaction manager. Such server programs cannot issue intermediate commit messages. Disclosure of the Invention

The prior art has hitherto only provided distributed transaction processing incurring significant performance overheads.

According to the present invention, there is provided a method of processing transactions in a distributed transaction processing system comprising first and second transaction processing means capable of communicating with each other and with resources which may be used and updated in the processing of transactions, each of the transaction processing means being adapted to issue a commit message indicating, at the end of a respective transaction, that changes to said resources shall be committed; the method comprising the steps of initiating a transaction on said first transaction processing means, said transaction including a client program resident in said first transaction programming means which includes a program call to a related server program resident in said second transaction processing means; passing said program call to said server program to cause said server program to run in said second transaction processing means; in response to a first type of program call, permitting only the first transaction processing means to issue a commit message in accordance with a commit protocol so that both client and server programs run as part of a single transaction and any resource updates by either program are only committed in response to the commit message from the first transaction processing means; and in response to a second type of program call, permitting the second transaction processing means to issue a commit message independently of the first transaction processing means so that the server program runs as part of a separate transaction and any resource updates by the server program are committed independently.

The invention also provides a distributed transaction processing system comprising first and second transaction processing means capable of communicating with each other; resources which may be used and updated by the processing means in the processing of transactions, each of the transaction processing means being adapted to issue a commit message indicating at the end of a respective transaction, that changes to said resources shall be committed; the first transaction processing means including means for executing as part of a transaction a client program which includes calls to a related server program and the second transaction processing means including means for executing such a server program; the system further including means for initiating a transaction including such a client program; means for passing a program call from such a client program to such a related server program; means responsive to a first type of program call to permit only the first transaction processing means to issue a commit message in accordance with a commit protocol so that both client and server programs run as part of a single transaction and any resource updates by either program are only committed in response to the commit message from the first transaction processing means; and means responsive to a second type of program call to permit the second transaction processing means to issue a commit message independently of the first transaction processing means so that the server program runs as part of a separate transaction and any resource updates by the server program are committed independently.

Transactions of the type in which the server program runs as part of a separate transaction are termed "wrapped transactions". A wrapped transaction is initiated and completed within another transaction that is already in-flight. The in-flight transaction is referred to as the outer transaction. Some characteristics of a wrapped transaction are as follows:

♦ Its recoverable resources are committed independently of the outer transaction's resources.

♦ All locks it acquires are freed before returning control to the calling transaction.

♦ It can run at the same location as the outer transaction or at a different one.

4 It can issue intermediate commit, points independently of the outer transaction. These do not affect the outer transaction. ♦ It can initiate wrapped transactions and thus act as an outer transaction with respect to other wrapped transactions.

♦ It can fail independently of the outer transaction.

Some characteristics of an outer transaction that initiates wrapped transactions are as follows:

♦ If it fails after its wrapped transactions commit, the wrapped transaction's recoverable resources remain committed and are not rolled back.

4 It can initiate wrapped transactions serially or concurrently.

♦ It can define new transaction context characteristics for the wrapped transaction that are different from its own.

Both outer and wrapped transactions can initiate or participate in, other types of transactions, e.g. nested transactions. Thus, a distributed application may be made up of a variety of elements, some completely co-ordinated, and some more independent.

Prior art distributed applications have a significant performance overhead compared to local applications, particularly when a two (or three) phase commit protocol is used. Wrapped transactions significantly improve the performance of distributed applications where resource access and update co-ordination between remote portions of the application is not essential.

The major advantage of wrapped transactions in the method and system of the invention is improved performance in a distributed system. For example, the following savings would be made over regular distribute transactions using a full two-phase-commit protocol:

♦ The two flows for two-phase-commit between the outer and wrapped transaction are eliminated. ♦ Participant log record forcing for two-phase-commit in the wrapped transaction, with respect to the outer transaction, is eliminated.

♦ Any communication connection between the outer and wrapped transaction can be freed as soon as the wrapped transaction completes, instead of being held until the outer transaction commits.

In performance measurements, the path-length between two remote CICS systems (using the CICS Intersystem Communication Method) to initiate, commit and terminate a wrapped transaction was found to be roughly 70% of that needed for a regular transaction that uses two-phase-commit to co-ordinate its updates with the outer transaction.

Additionally, there are throughput benefits that arise from freeing communication connections early. Also, more concurrency can be gained by running the wrapped transactions in parallel. In addition, the wrapped transaction cannot be in an in-doubt state with respect to the outer transaction. This avoids holding long in-doubt locks on shared data after failures.

The invention will now be described, by way of example only, with reference to the following drawings in which:

Figure 1 is an overview of an online transaction processing system suitable for the implementation of distributed transaction processing according to the invention,-

Figure 2 shows an overview of a distributed transaction processing system in which two of the systems of Figure 1 communicate with each other;

Figure 3 illustrates the operation of a distributed program link feature employed in the system of Figure 2;

Figure 4 shows further detail of the distributed program link of Figure 3. Figure 5 illustrates message flow between client and server as part of a single transaction;

Figure 6 illustrates message flow between client and server as part of multiple wrapped transactions; and

Figures 7A and 7B are a flow diagram illustrating a transaction processing method according to the invention.

Detailed Description of the Invention

Figure 1 shows a CICS transaction processing sytem including associated hardware and software. The hardware includes terminals such as 10 and databases and files such as 11.

A host computer operating system 12, such as MVS/ESA, VSE/ESA or OS/2 EE, supplies general data processing services to CICS software 13. The CICS software may be regarded as a subsidiary operating system which provides specialised on-line services to provide an environment for execution of on-line application programs 14, typically written by a customer for a specific on-line transaction processing application.

Application programs give users online access to their data and the ability to send messages to other CICS users. In addition, application programs running under CICS can communicate with other programs running elsewhere in the same computer system, or (given the appropriate network support) with other computing systems.

The CICS software 13 includes Data communication functions 15 which provide an interface between CICS and local or remote terminals to make the input or output of data easier. They provide a degree of device independence and format independence for application programs. There are also multiregion operation (MRO) and intersystem communication (ISC) facilities. Data handling functions 16 provide an interface between CICS and stored data. They allow the data to be read or updated, while preventing unauthorised access and protecting the data from corruption. CICS has interfaces to database products and to standard file access methods. CICS also has routines to handle queues and scratchpad data used within itself. Application program services 17 provide an interface between CICS and the application programs 14. System services 18 provide an interface between CICS and the operating system. They include functions to control CICS, and to share resources.

As was explained in connection with the prior art, CICS software 13 has intercommunication facilities which allow two or more separate physical systems or two or more regions within the same host to communicate and/or share terminals and other resources. The two modes of intercommunication are multiregion operation (MRO) and intersystem communication (ISC). These assist with the implementation of co-operative and distributed processing. There are several methods of intercommunication comprising function request shipping, distributed transaction processing, asynchronous processing, transaction routing and distributed program link.

The present invention is implemented in an intersystem communication configuration as illustrated in Figure 2, though it may also be applied in a multiregion operation environment. The system of Figure 2 comprises two CICS software systems 20 and 21, each with their associated terminals 22, 23 and data files 24, 25 connected by a communications link 26.

Specifically, the invention is implemented in the system of Figure 2, by means of the Distributed Program Link (DPL) method of intercommunication, illustrated in Figur^p 3.

The CICS distributed program link (DPL) enables CICS application programs to run programs residing in other CICS regions by shipping program-control LINK requests. An application can be written without regard for the location of the requested programs; it simply uses program-control LINK commands in the usual way. Entries in the CICS program definition tables allow the system programmer to specify that the named program is not in the local region (known as the client region) but in a remote region (known as the server region). Alternatively, the location of the remote program can be specified on the LINK command itself.

Client programs can run in a CICS intercommunication environment and use DPL without being aware of the location of the server program. The location of the server program is specified in the installed program resource definition.

In Figure 3, a client program 30 (PROG1) is running as part of a transaction 31 (AAAA) in a first transaction processing system 32 (CICX) . The program 30 issues a program-control LINK command for a server program 33 (PR0G2) running in a second transaction processing system 34 (CICY). It does this by specifying the following sequence of instructions:-

EXEC CICS LINK PROGRAM ('PR0G2') SYSID ('CICY^r) TRANSIT) ('AAAA')

These identify the remote program name, the remote system and the name of the transaction.

The transaction AAAA is duplicated at 35 in remote system 34 and the required server program is run under control of a mirror program (DFHMIRS) 36. The mirror program recreates the original LINK request and issues it on system 34. When the server program completes its task, the mirror program returns control to program 30 (PR0G1) and passes any data back to system 32 via an allocated communication data area (COMMAREA).

The operation of the DPL is illustrated in rather more detail on Figure 4 in which again a transaction 40 (AAAA) in system CICX includes a client program PR0G1 (not separately shown) with a LINK command to a program PR0G2 in a remote system CICY. In the client region the LINK command is passed over line 41 to the CICS command-level control programs 42 starting with an EXEC interface program DFHEIP. DFHEIP invokes a Program Control request processor DFHEPC which determines that the requested server program is on another system CICY. It calls an Inter System program DFHISP to send the request to the other system. Before sending the request to the other system, DFHISP calls a transformer program DFHXFP 43 over line 44 to transform the request into a form suitable for transmission to the other system over line 45.

The intercommunication component uses CICS terminal-control facilities to send the request to the other system CICY. The request to this particular server system (or region) causes the communication component in the client region (CICX) to precede the formatted request with the identifier of the appropriate mirror transaction 46 to be attached in the server region (CICY).

This transaction name must be defined in the server region as a transaction that invokes the mirror program DFHMIRS. To initiate any user-defined mirror transaction, the client program specifies the transaction name on the LINK request. Alternatively, the transaction name can be specified on the TRANSID option of the program resource definition.

As indicated by line 47 , the mirror transaction uses another instance of the transformer program 48 (DFHXFP) to decode the formatted link request. The mirror then executes the corresponding command, thereby linking to the server program PR0G2. When the server program issues the RETURN command, the mirror transaction uses the transformer program to construct a formatted reply over line 49. Finally, over line 50, the mirror transaction returns this formatted reply to the client region. In that region (CICX) in the example), the reply is decoded, again using the transformer program, and used to complete the original request made by the client program. Further detail of the operation of the mirror transaction technique can be found in US Patent 4274139.

In order to explain how the invention is implemented using distributed program link, it is desirable first to discuss some fundamental aspects of transaction processing in CICS systems such as those of Figures 1 and 2. In particular, concepts of integrity and recoverability are important and depend on how transactions themselves are delimited.

Where many users have access to the same data, there is always a chance that several of them will try to change the same record at the same time. Rather than allow this to happen, CICS ensures that one operator's updating of data is complete before another's may start.

During normal execution of a task, CICS logs information about all protected data that is being changed. This protected data is called a recoverable resource. The term applies to any resource for which recovery information is recorded (and which can therefore be recovered by reversing or "backing out" the changes made to it). It covers, among other things, certain transient data and temporary storage queues, and databases.

CICS puts the information about this protected data in the dynamic log (an area of storage allocated to the transaction as required). The log information is deleted after the successful completion of the task. However, if for any reason the task isn't completed, the data changes can be reversed, restoring the protected data to its original state.

CICS carries out dynamic transaction backout (DTB) to manage this recovery. If a transaction fails, due perhaps to application program error, data access error, transmission error, or because an operator decides to cancel a transaction, DTB reverses the updates that have been carried out by the transaction involved.

The process of cancelling changes in data works backwards from the last change before the failure, hence the name dynamic transaction backout. The backout occurs within the same task. This safeguards other tasks from the possibility of using corrupted data, because modified data is not released for use by them ("committed") until the current task has finished with it.

Application programs can specify intermediate synchronisation points (syncpoints) . These are points at which data updates or modifications are logically complete. Sync points delimit a logical unit of work (LUW). If there is a failure, a sync point tells CICS that changes made before that point (that is, during a preceding LUW) do not need to be backed out. Sync points help to speed up and simplify recovery from failure in a long-running task.

If DTB is employed, it can be followed by a restart function which allows the transaction to be retried immediately.

Transaction restart is an optional facility that allows a cancelled transaction to be restarted automatically without intervention by the terminal operator, provided that certain conditions are met. The facility allows the application program to perform additional recovery functions written by the programmer.

If an application program runs into problems, it can choose to call a ROLLBACK facility to cancel the changes it has made in all recoverable resources during the current transaction. These are then restored to the state prevailing at the previous syncpoint.

These transaction recovery functions are usually transparent to the terminal user.

CICS is a transaction manager that does not require the programmer to explicitly code START-TRANSACTION and END-TRANSACTION delimiters. Instead, CICS initiates programs within the scope of a transaction. One can imagine that CICS has issued a START-TRANSACTION request on behalf of the program before invoking it. After the program ends and returns control to CICS, CICS issues an END-TRANSACTION on behalf of the program.

CICS manages the execution units or threads (in CICS terminology these are called "tasks") under which the programs run. How the execution units are managed varies from one CICS implementation to another. CICS also provides an application programming interface (API) command for the programmer to split the transaction delimited by CICS into smaller consecutive transactions. This API command is known as EXEC CICS SYNCPOINT, and can be thought of roughly as an END-TRANSACTION immediately followed by a START-TRANSACTION. Thus, it is impossible for the program to execute any code within the CICS environment without it being part of a transaction. At SYNCPOINT, all recoverable resources are committed and locks are freed. Cursor positions in files and databases are usually lost too, although in some cases changes to CICS and related products are being introduced to preserve cursors. Program and state storage is kept across SYNCPOINTs. The SYNCPOINT API command also includes an. option for the program to issue a ROLLBACK.

CICS also provides an API command for the program to return control to its caller which could either be another program, or to the CICS system itself. This is the EXEC CICS RETURN command.

Returning now to the distributed program link (DPL), as has been described, this permits a CICS program, DELILAH say, to call another CICS program, SAMSON say, that is located in a different CICS system. In this case, DELILAH is referred to as the client program and SAMSON as the server program (a server program can act as a client with respect to another program). The server program is called by means of the EXEC CICS LINK API command. However, there are two ways of using DPL, with and without an option on the LINK command known as SYNCONRETURN. These are illustrated in Figures 5 and 6, where DELILAH is resident in a system CICS1 and SAMSON is resident in a second system CICS2. The steps of a method of transaction processing using both options are further illustrated in the flow diagram of Figures 7A and 7B.

The steps illustrated in Figure 7A are common to both options and will be described first. In both cases, a transaction TXN-1 is started (step 70) in a first CICS system CICS1 and invokes the client program, DELILAH in step 71. DELILAH includes an EXEC CICS LINK command which, when executed, causes the issue at step 72 of a LINK request for a specified server program SAMSON. The LINK request may be for a remote or local server and this is determined at step 73. If SAMSON is on CICSl, the request is processed locally (step 74). If SAMSON is on CICS2, a communication connection is established at step 75. CICSl then determines if the LINK command also specified SYNCONRETURN (step 76) and, if it did, sets a flag in data to be shipped to CICS2 (step 77). The LINK request is shipped to CICS2 (step 78) where it starts the mirror program DFHMIRS (step 79). The CICS2 system then determines, in step 80, whether the SYNCONRETURN option is specified in the program LINK request.

Considering first the non SYNCONRETURN option with reference to Figure 5, the CICSl system includes recoverable resources 50 which may be updated by DELILAH via line 52. As the resources are updated, the changes on line 52 are recorded in a log 51 as redo and undo records to permit later recovery. The changes are not irrevocably committed until an actual or implicit SYNCPOINT is taken at the end of the transaction. At this time CICSl "forces" the log 51 on line 53 to make the changes permanent. "Forcing" means that the log records, which were held in the log 51, are physically written to disk storage and the log maybe flushed.

Without SYNCONRETURN, as shown on the right hand side of Figure 7B, the mirror program LINKS to the server program SAMSON in the CICS2 system. SAMSON is also able to update recoverable resources 54 in the CICS2 system and to log the changes in a log 55 (step 92). However, without the SYNCONRETURN option, as illustrated in Figure 5, SAMSON runs as part of DELILAH'S transaction. When SAMSON finishes by executing an EXEC CICS RETURN command, it returns control to the client DELILAH in CICSl (step 93), DELILAH resumes execution (step 94) until it SYNCPOINTS, at step 95, which initiates a two-phase commit process (step 96) between CICSl and CICS2. If this is successful (step 97), all the recoverable resources 50 and 54 updated by both SAMSON and DELILAH will be committed (step 99). The server, SAMSON, is not permitted to commit independently. If either DELILAH or SAMSON fails, then all the recoverable resources updated by both of them will be backed out (step 98). When DELILAH terminates, it returns control to CICSl (step 100) and the single transaction, TXN-1, is ended (step 101). In the example of Figure 5, DELILAH LINKs to SAMSON twice without the SYNCONRETURN option and then terminates, causing all resources updated by DELILAH and SAMSON to be committed. There is one transaction (logical unit of work) in this example (TXN-1). In CICS terminology, the client commits the logical unit of work both for the client and server resources either with explicit commands in the client program or with an implicit syncpoint produced by CICS when the client task ends.

Commitment of shared resources, such as 50 and 54, requires that a full two-phase commit protocol (step 96) is employed to protect the resources. In phase 1 of the process, the client system, CICSl, as co-ordinator polls all servers to see if they are prepared to commit by issuing a PREPARE request. Upon receiving the PREPARE request, the server system CICS2 when ready, forces a PREPARED record to its log 55 which causes all associated redo-undo records to be forced to the log as well.

The client enters phase 2 when it irrevocably makes the decision to commit or abort the transaction. If all server CICS systems, such as CICS2, agree to commit, the client CICS system. CICSl, records the commit decision in a record in log 5] which is forced out on line 53. The CICSl system then broadcasts the COMMIT message to each server CICS system. If any server system does not agree to commit or respond within a time limit, the client records a BACKOUT decision in its log and broadcasts the BACKOUT message to each server CICS system (step 98).

The servers respond by committing or backing out their part of the transaction as appropriate and acknowledging to the client with a COMMITTED or BACKOUT message. After the client has received all phase 2 acknowledgements, it then terminates the transaction (steps 100 and 101).

Using this approach, from the first invocation of the server until the two phase commit process is completed, a single communication session must be maintained between the CICSl and CICS2 systems as illustrated by dashed lines in Figure 5. The connection is freed as the transaction terminates (step 102). While two-phase commit is essential for the protection of shared resources accessed by distributed systems, the two-way flow of messages between the participants can take up a considerable time.

The SYNCONRETURN option on the distributed program link permits certain classes of distributed transaction to avoid the need for two-phase commit. The option is specified as an additional API command "SYNCONRETURN" following the "EXEC CICS LINK" command. Message flow is illustrated in Figure 6 which shows the same two CICS systems CICSl and CICS2 and the same resources and logs, numbered in this case 50', 51', 54' and 55'. The steps of the SYNCONRETURN path are illustrated on the left hand side of Figure 7B.

With the SYNCONRETURN option, SAMSON runs as part of a separate transaction (TXN-2) to DELILAH. After storage of a SYNCONRETURN flag in CICS2 storage (step 81), CICS2 starts the new transaction TXN-2 (step 82). The transaction invokes SAMSON via the mirror program (step 83) and SAMSON updates resources 54' and logs changes in log 55' as it runs (step 84).

When SAMSON completes and RETURNS (step 85), CICS2 SYNCPOINTS (step 86) and forces log 55' on line 60 to commit resources 54' immediately before returning control to DELILAH. CICS2 sends the RETURN message to DELILAH and ends Transaction 2 (step 87). At this point, the communication connection is also freed (step 88).

Execution of DELILAH then resumes, as part of Transaction 1, until, in the example of Figure 6, a further LINK to a second server program VICTOR is reached. The communications connection between CICSl and CICS2 is re-established and the LINK command establishes a third transaction (TXN3) which invokes VICTOR. Exactly as with SAMSON, VICTOR updates CICS2 resources 54' and writes records to log 55' until it completes. Again log 55' is forced on line 61 and the resource changes are committed prior to the final RETURN to DELILAH, which ends Transaction 3 and frees the communication connection. Execution of DELILAH resumes (step 89) until it terminates either with an explicit EXEC CICS SYNCPOINT (step 90) or an implicit SYNCPOINT issued by CICSl. Immediately following the SYNCPOINT, DELILAH forces log 51' to commit resources 50'. However, it will be noted that there is no co-ordination of this commit process with SAMSON or VICTOR and thus no two-phase commit protocol need be followed. Also, the communication connection between CICSl and CICS2 is freed when no server is active.

SYNCONRETURN specifies that the server region should take an independent SYNCPOINT on successful completion of the server program. The server's resources are committed in a separate logical unit of work immediately prior to returning control to the client, that is, an implicit syncpoint is issued for the server just before the server returns control to the client. SYNCONRETURN could be used when the client program is not updating any recoverable resources, for example, when performing screen handling. However, if the client does have recoverable resources, they are not committed at this point. They will be committed when the client itself syncpoints or in the implicit syncpoint at client task end.

The following restrictions apply to wrapped transactions, as implemented:-

♦ The wrapped transaction must run at a different location from the outer transaction. There is an option to run it locally, but this is intended for testing purposes only.

♦ The outer transaction can initiate wrapped transactions serially only.

♦ The outer transaction is limited in the transaction context information it can redefine for the wrapped transaction. It can alter the transaction code, which is a grouping mechanism that has a major influence on CICS execution. The other pieces of context information are inherited by the wrapped transaction from the outer transaction. It is possible to choose dynamically where the server is to run, e.g. for the purposes of work-load balancing, or to execute near the data it needs to access.

There follow some examples of applications where wrapped transactions are appropriate:

a) Updating remote central data

The outer transaction could be dealing with the end user interface portion of the application, and updating local recoverable data purely to gather the input from multiple user interactions, and to perform some validation. After a few user interactions, a single wrapped transaction could be used to update the remote central data. On completion of the remote update, the local data could be deleted. This is a typical client server example.

b) Long lived outer transaction

A long lived outer transaction could be processing sets of records, each set being associated with a different user. For each user encountered, a wrapped transaction could be initiated to deal with that user's records. An example of data of this type, is input (sequential files) arising from portable devices that are intermittently connected to the network. To ensure that the appropriate resource access security checks are made, it is usually vital that the wrapped transactions execute on behalf of the appropriate user (the real originator of the input), rather than a generic system user associated with the outer transaction. This is also important for chargeback purposes.

c) Read only wrapped transactions

Where a remote portion of a transaction is read only, and where it is not essential that the remote data be consistent with data at another location being updated within the same outer transaction, then a wrapped transaction is appropriate. Thus, there is no need to wait till the outer transaction commits to free any locks. A specific example could be where large amounts of less volatile data are held centrally, such as a customer file, and order data is held locally by department say. The departmental application that produces orders could access the central customer file to retrieve name and address information using a wrapped transaction, but elements and the wrapped transaction could execute within the scope of a single outer transaction.

Co-ordination of local departmental and remote central data

One example is where local and central data are replicated, and both are being kept up to date. Local data is used to satisfy all read requests. When an update is requested, a wrapped transaction modifies the central data. When that completes, the local data is updated. Alternatively, the local data could be updated first, but flagged that the central data has not yet been updated. The local updates could become visible to other local users immediately. When the central updates are completed, the local data could be flagged to indicate the corresponding central updates are completed.

This approach can be used for multi-level updates and replication. By using "suspense" files and/or a general utility which intermittently checks for differences between the local and remote data, data consistency can be maintained.

Claims

1. A method of processing transactions in a distributed transaction processing system comprising first and second transaction processing means capable of communicating with each other and with resources which may be used and updated in the processing of transactions, each of the transaction processing means being adapted to issue a commit message indicating, at the end of a respective transaction, that changes to said resources shall be committed; the method comprising the steps of:

initiating a transaction on said first transaction processing means, said transaction including a client program resident in said first transaction programming means which includes a program call to a related server program resident in said second transaction processing means;

passing said program call to said server program to cause said server .program to run in said second transaction processing means;

in response to a first type of program call, permitting only the first transaction processing means to issue a commit message in accordance with a commit protocol so that both client and server programs run as part of a single transaction and any resource updates by either program are only committed in response to the commit message from the first transaction processing means; and

in response to a second type of program call, permitting the second transaction processing means to issue a commit message independently of the first transaction processing means so that the server program runs as part of a separate transaction and any resource updates by the server program are committed independently.

2. A method as claimed in Claim 1 in which resources are updated by the server program including the further steps of logging the updates as they are made and restoring the resources to their original state if the second transaction processing means fails to issue a commit message in response to said second type of program call.

3. A method as claimed in Claim 1 or Claim 2 in which resources are updated by the server program including the further steps of locking the resources during updating and freeing them upon issue of a commit message by said second transaction processing means.

4. A method as claimed in any preceding claim including the step of detecting in the program call the absence or presence of an indication that independent commitment by the second transaction processing means is permitted, such absence or presence distinguishing the first and second types of program call respectively.

5. A method as claimed in any one of Claims 1 to 4 in which said commit protocol is a two-phase commit protocol.

6. A distributed transaction processing system comprising first and second transaction processing means capable of communicating with each other;

resources which may be used and updated by the processing means in the processing of transactions, each of the transaction processing means being adapted to issue a commit message indicating at the end of a respective transaction, that changes to said resources shall be committed;

the first transaction processing means including means for executing as part of a transaction a client program which includes calls to a related server program and the second transaction processing means including means for executing such a server program;

the system further including means for initiating a transaction including such a client program;

means for passing a program call from such a client program to such a related server program; means responsive to a first type of program call to permit only the first transaction processing means to issue a commit message in accordance with a commit protocol so that both client and server programs run as part of a single transaction and any resource updates by either program are only committed in response to the commit message from the first transaction processing means; and

means responsive to a second type of program call to permit the second transaction processing means to issue a commit message independently of the first transaction processing means so that the server program runs as part of a separate transaction and any resource updates by the server program are committed independently.

7. A system as claimed in Claim 6 in which the first and second transaction processing means are physically separate and independent systems and are in communication via a communication link.

8. A system as claimed in either Claim 6 or Claim 7 including/ log means for logging updates to the resources by such a server program as they are made and restoring means for restoring the resources to their original state if the second transaction processing means fails to issue a commit message in response to said second type of program call.

9. A system as claimed in any one of Claims 6, 7 or 8 including resource locking means for locking resources during updates by the server program, the locking means being responsive to the issue of a commit message by the second transaction processing means to free the locked resources.

10. A system as claimed in any one of Claims 6 to 9 including means for detecting in a program call, the absence or presence of an indication that independent commitment by the second transaction processing means is permitted.

11. A system as claimed in any one of Claims 6 to 10 in which said commit protocol is a two-phase commit protocol.