Electrical computers and digital processing systems: multicomput – Distributed data processing
Reexamination Certificate
1999-09-01
2002-10-08
Geckil, Mehmet B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Distributed data processing
C709S217000
Reexamination Certificate
active
06463456
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to the distributed computing. More specifically, the present invention relates to the field of registration in distributed transaction processing computing.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time computers have become indispensable in many fields of human endeavor including engineering design, machine and process control, and information storage and access. In the early days of computers, companies such as banks, industry, and the government would purchase a single computer which satisfied their needs, but by the early 1950's many companies had multiple computers and the need to move data from one computer to another became apparent. At this time computer networks began being developed to allow computers to work together.
Computer networks are capable of performing jobs that no single computer could perform and they allow low cost personal computer systems to connect to larger systems to perform tasks that such low cost systems could not perform alone. In order for computer systems to cooperate in a network to perform some complex job, software must be developed which efficiently delegates parts of the chore or tasks to different computers in the network.
The International Standards Organization (ISO) has defined an ISO Distributed Transaction Processing (DTP) standard to support the synchronization and co-ordination of distributed applications to ensure that transactions can be reliably completed on multiple open systems. X/Open is an industrial standards organization that has defined a reference module for the OSI DTP. X/Open has also defined application program interfaces and system interfaces between system components defined in the model.
The X/Open model defines the various system elements that work together to perform distributed transaction processing. In particular, the X/Open model defines Transaction Managers (TMs) and Resource Managers (RMs) that work together, along with other elements, to facilitate distributed processing. Transaction Managers are the components that assign identifiers to transactions, monitor the progress of transactions, and take responsibility for transaction completion and coordinating failure recovery. Resource Managers are the components that provide access to resources, such as database systems. Typically, the Transaction Manger coordinates the start and completion of the global transactions of each participating Resource Manager. For example, when an application calls the Transaction Manager to start a global transaction, the Transaction Manager assigns a global transaction ID and informs the Resource Manager about the new transaction branch. After the application performs operations on the Resource Manager within the global transaction, the Transaction Manager calls the Resource Manager to either commit or rollback the transaction branch. Also, if failure recovery is needed the Transaction Manager recalls the failed transaction from the Resource Manager and continues to complete the failed transaction.
In order for Transaction Managers and Resource Managers to work together to facilitate distributed processing, the X/Open model requires that all Resource Managers register to the Transaction Manager before the distributed transaction is begun. This registration makes the Resource Manager known to the Transaction Manager, such that they can work together to complete transactions.
Currently, some systems use a registration system typically referred to as “static registration.” In static registration, all Resource Managers are required to the Transaction Manager before any distributed transaction occurs. In particular, because there is no efficient way for a Transaction Manager to dynamically know what Resource Managers are going to be involved in a particular distributed transaction, current static registration methods require that all Resource Managers register with the Transaction Manager when the Transaction Manager is constructed. This static registration is required even if a particular Resource Manager will not participate in an upcoming distributed transaction.
When a distributed transaction is then started, the Transaction Manager must inform all registered Resource Managers to start a transaction even though some of those Resource Managers will not be involved in the current transaction.
The requirement that all Resource Managers register beforehand with the Transaction Managers and that all Resource Managers, even those not participating in a transaction, be notified when a transaction starts results in transactional complexity that causes delay and other significant inefficiencies. In particular, if all the Resource Managers must register to the Transaction Manager even though some of those Resource Managers are not involved in the current transaction, then each transaction causes unnecessary flows. For example, if there are two Resource Managers involved in the current transaction and there are four Resource Managers registered to the Transaction Manager, then there will be six extra flows per transaction (i.e., two extra xa_start, two extra xa_end, and two extra xa_prepare). Additionally, these extra flows may involve distributed processes that can cause even more overhead.
For this reason there has recently been other attempts to utilize “dynamic registration” of the Resource Managers. Unfortunately, some of these techniques have also had significant drawbacks. One significant drawback is the loss of execution control by the Transaction Manager. In particular, the Transaction Manager does not have control over the starting of transactions as it does when static registration is used. Instead, the Transaction Manager waits for the Resource Manager to inform the Transaction Manager that it is involved in a new transaction. In a normal case, this can be an efficient way to let the Resource Manager participate in a transaction. However, in some cases a new transaction will be instantiated by the Resource Manager in the process of ending a global transaction and an unpredictable error will occur.
There thus remains no effective way to register Resource Managers with Transaction Managers in an X/Open distributed transaction system Thus, what is a needed is a mechanism providing an efficient way to use register and control the transaction involvement of Resource Managers without requiring unnecessary Resource Manager involvement.
DISCLOSURE OF THE INVENTION
The preferred embodiment provides an improved system and method for registration of Resource Managers with Transaction Managers in an X/Open distributed processing environment. The preferred system and method creates and stores a transactional resource in a container when the first execution method goes to the Resource Manager. The transactional resource represents the Resource Manager to the Transaction Manager. The transactional resource uses X/Open static registration procedures to inform the Resource Manager about the new transaction. The transactional resource is then registered to the Transaction Manager. In this way, only those Resources Managers that are involved in a transaction are registered and made known to registered to the Transaction Manager. Additionally, because static registration procedures are used, the Transaction Manager maintains control of the transaction.
Additionally, in the preferred embodiment the transactional resource implements the commit control interfaces on behalf of the Resource Manager. Thus, when an application decides to a commit (or rollback) a transaction, the commit (or rollback) command will call the transactional resource and the transactional resource will call the Resource Managers for this transaction with the appropriate command.
In the preferred embodiment, the transactional resource is created in and by a container that additionally stores information which relates to corresponding Resource Managers. When a transaction is started that operat
Kan Teresa C.
McKeehan Michael D.
Geckil Mehmet B.
Schmeiser Olsen & Watts LLP
LandOfFree
Efficient registration for distributed transaction systems does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Efficient registration for distributed transaction systems, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient registration for distributed transaction systems will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2998878