+

WO1993018454A1 - Systeme decentralise de traitement de transactions - Google Patents

Systeme decentralise de traitement de transactions Download PDF

Info

Publication number
WO1993018454A1
WO1993018454A1 PCT/GB1992/001218 GB9201218W WO9318454A1 WO 1993018454 A1 WO1993018454 A1 WO 1993018454A1 GB 9201218 W GB9201218 W GB 9201218W WO 9318454 A1 WO9318454 A1 WO 9318454A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
program
transaction processing
processing means
resources
Prior art date
Application number
PCT/GB1992/001218
Other languages
English (en)
Inventor
Susan Malaika
Michael John Brady
Geoffrey Meacock
Original Assignee
International Business Machines Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corporation filed Critical International Business Machines Corporation
Publication of WO1993018454A1 publication Critical patent/WO1993018454A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying

Definitions

  • the present invention relates to a method of and a system for distributed transaction processing.
  • On-line transaction processing 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.
  • CICS IBM Customer Information Control System
  • GC33-0155-4 CICS General Information
  • API Application Program Interface
  • 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.
  • LW logical unit of work
  • 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.
  • CICS transaction processing systems
  • ISC intersystem communication
  • MRO multi-region operation
  • Transaction routing enables a terminal in one CICS system to run a transaction in another CICS system
  • Asynchronous processing enables a CICS transaction to initiate a transaction in a remote system and to pass data to it;
  • DTP distributed transaction processing
  • DPL distributed Program Link
  • CICS may also communicate with external shared databases and the CICS/ESA 3.2 system handled such communication through a Resource Manager Interface (RMI).
  • RMI Resource Manager Interface
  • 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.
  • 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.
  • 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
  • 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
  • wrapped transactions 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.
  • 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:
  • 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
  • Figures 7A and 7B are a flow diagram illustrating a transaction processing method according to the invention.
  • FIG. 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.
  • 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.
  • 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.
  • MRO multiregion operation
  • ISC intersystem communication
  • 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.
  • 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.
  • DPL Distributed Program Link
  • the CICS distributed program link 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.
  • 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:-
  • 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.
  • 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).
  • PR0G1 program 30
  • COMMAREA allocated communication data area
  • 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.
  • 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.
  • 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.
  • the client program specifies the transaction name on the LINK request.
  • the transaction name can be specified on the TRANSID option of the program resource definition.
  • the mirror transaction uses another instance of the transformer program 48 (DFHXFP) to decode the formatted link request.
  • the mirror executes the corresponding command, thereby linking to the server program PR0G2.
  • the server program issues the RETURN command
  • the mirror transaction uses the transformer program to construct a formatted reply over line 49.
  • the mirror transaction returns this formatted reply to the client region.
  • the reply is decoded, again using the transformer program, and used to complete the original request made by the client program.
  • CICS ensures that one operator's updating of data is complete before another's may start.
  • 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.
  • DTB dynamic transaction backout
  • Syncpoints 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.
  • DTB 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.
  • 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.
  • 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.
  • API application programming interface
  • 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.
  • SYNCPOINT all recoverable resources are committed and locks are freed.
  • 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.
  • DELILAH DELILAH
  • SAMSON SAMSON
  • the server program is called by means of the EXEC CICS LINK API command.
  • SYNCONRETURN 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.
  • 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 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 determines, in step 80, whether the SYNCONRETURN option is specified in the program LINK request.
  • the CICSl system includes recoverable resources 50 which may be updated by DELILAH via line 52.
  • 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.
  • 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.
  • SAMSON 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).
  • DELILAH When DELILAH terminates, it returns control to CICSl (step 100) and the single transaction, TXN-1, is ended (step 101).
  • DELILAH LINKs to SAMSON twice without the SYNCONRETURN option and then terminates, causing all resources updated by DELILAH and SAMSON to be committed.
  • 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.
  • step 96 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.
  • the client system, CICSl as co-ordinator polls all servers to see if they are prepared to commit by issuing a PREPARE request.
  • the server system CICS2 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).
  • server CICS systems such as CICS2
  • 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).
  • 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.
  • SAMSON runs as part of a separate transaction (TXN-2) to DELILAH.
  • CICS2 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).
  • 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).
  • 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 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.
  • 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.
  • 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.
  • 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.
  • Local and central data are replicated, and both are being kept up to date.
  • Local data is used to satisfy all read requests.
  • a wrapped transaction modifies the central data.
  • the local data is updated.
  • 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.
  • 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.
  • "suspense" files and/or a general utility which intermittently checks for differences between the local and remote data, data consistency can be maintained.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)

Abstract

Un procédé et un système pour le traitement de transactions réparti entre un premier et un second moyen de traitement des transactions en communication mutuelle utilisent un programme client dans le premier moyen de traitement de transactions qui appelle un programme serveur dans le second moyen de traitement des transactions. Un premier type d'appel de programme serveur permet uniquement au premier moyen de traitement des transactions d'engager des ressources aussi bien pour le client que pour le serveur, les deux programmes faisant effectivement partie d'une seule transaction. un second type d'appel de programme permet au second moyen de traitement des transactions d'engager des ressources d'une manière indépendante, si bien que le programme serveur est exécuté comme partie d'une transaction séparée.
PCT/GB1992/001218 1992-03-02 1992-07-06 Systeme decentralise de traitement de transactions WO1993018454A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9204440A GB2264796A (en) 1992-03-02 1992-03-02 Distributed transaction processing
GB9204440.3 1992-03-02

Publications (1)

Publication Number Publication Date
WO1993018454A1 true WO1993018454A1 (fr) 1993-09-16

Family

ID=10711323

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1992/001218 WO1993018454A1 (fr) 1992-03-02 1992-07-06 Systeme decentralise de traitement de transactions

Country Status (3)

Country Link
EP (1) EP0582681A1 (fr)
GB (1) GB2264796A (fr)
WO (1) WO1993018454A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100435101C (zh) * 2003-06-10 2008-11-19 国际商业机器公司 在软件环境中用于保持资源完整性的装置和方法

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE9300671D0 (sv) * 1993-03-01 1993-03-01 Sven Nauckhoff Work flow management
US6948070B1 (en) 1995-02-13 2005-09-20 Intertrust Technologies Corporation Systems and methods for secure transaction management and electronic rights protection
US7069451B1 (en) 1995-02-13 2006-06-27 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US7133845B1 (en) 1995-02-13 2006-11-07 Intertrust Technologies Corp. System and methods for secure transaction management and electronic rights protection
US6658568B1 (en) 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US7133846B1 (en) 1995-02-13 2006-11-07 Intertrust Technologies Corp. Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management
US5892900A (en) 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US7165174B1 (en) 1995-02-13 2007-01-16 Intertrust Technologies Corp. Trusted infrastructure support systems, methods and techniques for secure electronic commerce transaction and rights management
US6157721A (en) 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US20120166807A1 (en) 1996-08-12 2012-06-28 Intertrust Technologies Corp. Systems and Methods Using Cryptography to Protect Secure Computing Environments
US7095854B1 (en) 1995-02-13 2006-08-22 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5943422A (en) 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
US7124302B2 (en) 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
ATE412945T1 (de) 1995-02-13 2008-11-15 Intertrust Tech Corp Systeme und verfahren für ein sicheres übertragungsmanagement und elektronischerrechtsschutz
US7143290B1 (en) 1995-02-13 2006-11-28 Intertrust Technologies Corporation Trusted and secure techniques, systems and methods for item delivery and execution
GB2308468A (en) * 1995-12-20 1997-06-25 Ibm Data processing systems and methods providing interoperability between data processing resources
US20010011253A1 (en) 1998-08-04 2001-08-02 Christopher D. Coley Automated system for management of licensed software
US7590853B1 (en) 1996-08-12 2009-09-15 Intertrust Technologies Corporation Systems and methods using cryptography to protect secure computing environments
US5920861A (en) 1997-02-25 1999-07-06 Intertrust Technologies Corp. Techniques for defining using and manipulating rights management data structures
US7092914B1 (en) 1997-11-06 2006-08-15 Intertrust Technologies Corporation Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information
US6112181A (en) 1997-11-06 2000-08-29 Intertrust Technologies Corporation Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information
US7233948B1 (en) 1998-03-16 2007-06-19 Intertrust Technologies Corp. Methods and apparatus for persistent control and protection of content
US7243236B1 (en) 1999-07-29 2007-07-10 Intertrust Technologies Corp. Systems and methods for using cryptography to protect secure and insecure computing environments
US7430670B1 (en) 1999-07-29 2008-09-30 Intertrust Technologies Corp. Software self-defense systems and methods
EP1204913B1 (fr) 1999-07-30 2005-10-05 Intertrust Technologies Corp. Procedes et systemes de fourniture de donnees de transaction enregistrees au moyens de seuils et de protocole a plusieurs etages
US7406603B1 (en) 1999-08-31 2008-07-29 Intertrust Technologies Corp. Data protection systems and methods
US6985885B1 (en) 1999-09-21 2006-01-10 Intertrust Technologies Corp. Systems and methods for pricing and selling digital goods
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7590589B2 (en) 2004-09-10 2009-09-15 Hoffberg Steven M Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US20210240516A1 (en) * 2020-02-05 2021-08-05 International Business Machines Corporation Distributed transaction management

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4274139A (en) * 1978-06-15 1981-06-16 International Business Machines Corporation Digital telecommunication network having improved data processing systems

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3293839B2 (ja) * 1990-05-16 2002-06-17 インターナショナル・ビジネス・マシーンズ・コーポレーション 作業ユニットに合わせてコミット範囲を調整するコンピュータ・システム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4274139A (en) * 1978-06-15 1981-06-16 International Business Machines Corporation Digital telecommunication network having improved data processing systems

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PROCEEDINGS OF THE 15TH INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, August 1989, AMSTERDAM, NL pages 337 - 346 K. ROTHERMEL AND C. MOHAN: 'ARIES/NT: A Recovery Method Based on Write-Ahead Logging for Nested Transactions' *
PROCEEDINGS OF THE 7TH INTERNATIONAL CONFERENCE ON DATA ENGINEERING, April 1991, LOS ALAMITOS, CALIFORNIA, USA pages 286 - 293 M. HSU AND A. SILBERSCHATZ: 'Unilateral Commit: A New Paradigm for Reliable Distributed Transaction Processing' cited in the application *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100435101C (zh) * 2003-06-10 2008-11-19 国际商业机器公司 在软件环境中用于保持资源完整性的装置和方法

Also Published As

Publication number Publication date
GB9204440D0 (en) 1992-04-15
EP0582681A1 (fr) 1994-02-16
GB2264796A (en) 1993-09-08

Similar Documents

Publication Publication Date Title
WO1993018454A1 (fr) Systeme decentralise de traitement de transactions
US5923833A (en) Restart and recovery of OMG-compliant transaction systems
US9223823B2 (en) Transaction log management
JP4159175B2 (ja) 補償型リソース・マネージャ
US6233585B1 (en) Isolation levels and compensating transactions in an information system
US8909604B1 (en) Methods for returning a corrupted database to a known, correct state by selectively using redo and undo operations
US20190235974A1 (en) Transaction processing system, recovery subsystem and method for operating a recovery subsystem
US9830223B1 (en) Methods for repairing a corrupted database to a new, correct state
US5465328A (en) Fault-tolerant transaction-oriented data processing
US6873995B2 (en) Method, system, and program product for transaction management in a distributed content management application
US6665814B2 (en) Method and apparatus for providing serialization support for a computer system
US4868744A (en) Method for restarting a long-running, fault-tolerant operation in a transaction-oriented data base system without burdening the system log
US20040215998A1 (en) Recovery from failures within data processing systems
US7992148B2 (en) Issuing syncpoints during execution of a batch application to minimize or eliminate periods of record unavailability due to batch related record locking
JPH0784815A (ja) フォールト・トレラント・トランザクション指向データ処理システムおよび方法
US6874104B1 (en) Assigning recoverable unique sequence numbers in a transaction processing system
JP3491282B2 (ja) 回復ログの強制書込みの数を減らす方法及びデータ処理装置
US12099416B1 (en) Apparatus for resolving automatic transaction facility (ATF) failures
KR20080042881A (ko) 트랜잭션 일치 및 문제 상태
CN112148436A (zh) 去中心化的tcc事务管理方法、装置、设备及系统
US6571270B1 (en) Timeout detection facility
EP1247182A1 (fr) Conservation de la coherence d'objets non deterministes dupliques passivement
US6256641B1 (en) Client transparency system and method therefor
Barga et al. Persistent applications via automatic recovery
EP0817019B1 (fr) Méthode de traitement stratifié de transactions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IT LU MC NL SE

WWE Wipo information: entry into national phase

Ref document number: 1992914212

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1992914212

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1992914212

Country of ref document: EP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载