Method for using a transaction service synchronization interface to perform internal state clean up

[0002] 1. Field of the Invention

[0003] The present invention relates generally to transaction management in a distributed object computing environment, and more particularly, to a method for using a transaction service synchronization interface to perform container internal state clean-up after a transaction has completed.

[0004] 2. Description of the Related Art

[0005] The Common Object Request Broker Architecture (CORBA), an industry standard established by the Object Management Group (OMG), is designed to provide object-oriented, distributed computing standardization and interoperability. One aspect of the CORBA standard relates to transaction management, which ensures that transactions are properly handled across an object-oriented distributed system. Specifically, the Object Transaction Service (OTS) Specification, version 1.1, November 1997, herein incorporated by reference, specifies the transaction services requirements. In a CORBA compliant system, a transaction is viewed as a unit of work having the following characteristics:

[0006] A transaction is atomic; if interrupted by failure, all effects are undone (rolled back).

[0007] A transaction produces consistent results; the effects of a transaction preserve invariant properties.

[0008] A transaction is isolated; its intermediate states are not visible to other transactions. Transactions appear to execute serially, even if they are performed concurrently.

[0009] A transaction is durable; the effects of a completed transaction are persistent; they are never lost (except in a catastrophic failure).

[0010] The OTS 1.1 Specification defines interfaces that allow multiple, distributed objects to cooperate. In particular, each transaction is “atomic”—that is, each transaction is either completed (all changes committed) or the changes are rolled back. The defined interfaces enable objects to either commit all the changes or perform a rollback. One interface defined by the specification is the Synchronization Interface. The Synchronization Interface allows different system resources participating in transaction to be notified that transaction is about to complete (or “commit”), and therefore the resources can flush out any transient data to a database (i.e. store the data).

[0011] An object with transient state data is notified by the Transaction Service through the Synchronization Interface prior to the completion of a transaction, in order to flush any transient data to storage (i.e. the transient data is made “persistent”). This notification is performed by a “before_completion” operation. After the transaction has completed, the Transaction Service invokes an “after_completion” operation. An example of the syntax for these operations is shown in FIG. 1.

[0012] One problem posed by distributed transaction processing is that each portion of a distributed transaction may not be aware of when the transaction actually completes. As a result, temporary memory space used for the transaction may not be cleaned up after the transaction processing has completed. Therefore, it would be desirable to have a mechanism to notify individual objects that a particular transaction has completed and that any associated memory space may be cleaned (i.e. reallocated for use).

[0013] The present invention is a method for using a Synchronization Interface in a computer system compliant with a CORBA Object Transaction Service or the Java Transaction API (such as Java 2 Platform Enterprise Edition Reference Implementation) to perform internal state clean up in containers associated with a completed transaction. First, a synchronization object is registered for each new transaction in a container with a Transaction Manager compliant with either OTS or JTA. The Transaction Manager detects a completion of the transaction and then invokes an “after_completion” operation (method) on the synchronization object. This notifies each container involved in the completed transaction to perform internal memory space clean up.

[0014] Thus, the method uses an existing Synchronization Interface mechanism (originally designed to flush transient data to storage) to perform internal memory state clean up in containers. Since the Transaction Manager does not need to have specific knowledge of the container, no modifications are needed to the Transaction Manager. Also, since the Transaction Managers already cooperate among themselves, there is no need to create a whole new communication mechanism, which would add complexity and inefficiency.

[0015] The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

[0016] FIG. 1 illustrates the syntax of a CORBA-compliant Synchronization Interface;

[0017] FIG. 2 is a diagram of a typical J2EE reference implementation; and

[0018] FIG. 3 is a flowchart of the procedure of the present invention.

[0019] The following description is provided to enable any person skilled in the art to make and use the invention and sets forth the best modes contemplated by the inventor for carrying out the invention. Various modifications, however, will remain readily apparent to those skilled in the art, since the basic principles of the present invention have been defined herein specifically to provide a method for using a transaction service synchronization interface to perform internal state clean up.

[0020] Sun Microsystem's Java 2 Platform Enterprise Edition (J2EE) is a platform for constructing Java technology based multi-tier applications across a distributed, object-oriented enterprise. One specific J2EE-compliant implementation is known as the J2EE Reference Implementation or J2EE RI. The J2EE RI includes an implementation of a Java Transaction Service (JTS) and a Java Transaction API (JTA). The JTS is specified by the Java Transaction Service draft specification, version 0.95, Mar. 1, 1999, and the JTA is specified by the Java Transaction API specification, version 1.0.1, Apr. 29, 1999, both specifications herein incorporated by reference. The JTA specification specifies the high-level interfaces between a Transaction Manager and any other parties involved in a distributed transaction system, such as the application, the resource manager, and the application server. The JTS specification specifies the Transaction Manager, which supports the JTA specification at the high-level and implements the OTS 1.1 Specification at the low-level. The present invention can be implemented using a Transaction Manager compliant with either OTS or JTA, or both OTS and JTA.

[0021] A typical J2EE implementation 10 is illustrated in FIG. 2. The J2EE implementation 10 may be installed on one or more physical machines, as the J2EE standard does not specify any predefined hardware configuration. The standard architecture supports two types of components, Web components and Enterprise Java Bean (EJB) 141, 142 components, and also application clients. The Web components include Java Server Pages (JSP) 121 and servlets 122. The JSP components 121 may be accessed, for example, by a web browser 20 using HTTP. Each type of component is contained within a “Container” 12, 14, 16, 17 which provides an environment within which components or applications run. A J2EE implementation 10 may contain multiples of the same type of containers 16, 17 and the containers may exist in a distributed environment. Individual components can interact with each other across containers or with external databases 18. Each container has its own Transaction Manager 124, 144, 164 to manage transactions within the container. The Transaction Managers can communicate with other Transaction Managers to determine transaction status information.

[0022] J2EE RI provides a distributed application server environment and keeps track of various states for each component in each transaction. In general, only the Transaction Managers 124, 144, 164, however, know when a transaction has completed. For example, the J2EE RI might get involved in a transaction that is started by a client on a remote machine, but only the remote client and the Transaction Managers 124, 144, 164 know when the a transaction has completed. This creates a system maintenance problem for a J2EE RI environment. Specifically, without knowing when a transaction has completed, the J2EE RI does not know when to perform transient state clean up within each container 12, 14, 16, 17. Each container 12, 14, 16, 17 has memory space 123, 143, 163 used to store internal state information for each transaction. If the memory space 123, 143, 163 is not freed after a transaction has completed, the amount of space available for other transactions is reduced (causing “memory leaks”). Over time, these memory leaks may reduce system performance or even cause the system to crash. One possible solution is to modify the Transaction Manager implementation to perform the state clean up, but this would result in an undesirable coupling between the Transaction Manager and the J2EE RI. Also, any changes to the Transaction Manager interface may make it non-compliant with OTS 1.1. Thus, it would be desirable to implement an internal state clean up mechanism for each container after a transaction has completed, without modifying the current Transaction Manager implementation.

[0023] As described above, the J2EE system 10 needs to clean up the internal states in each container 12, 14, 16, 17 after a transaction completes, so that the allocated memory 123, 143, 163 is not used up. However, since one transaction may span multiple machines and processes, it is difficult for all the containers to know when to perform a clean up operation. The present invention uses the Synchronization Interface of a Transaction Manager that supports OTS or JTA in a unique way to trigger each container involved in a transaction to perform a clean up operation. The present mechanism has not previously been proposed or recommended, but may be implemented without adversely affecting the Synchronization Interface operation.

[0024] The procedure of the present invention is illustrated in FIG. 3. According to the present invention, the J2EE RI registers a Synchronization object with the Transaction Manager for each transaction that is started, or when the J2EE RI first learns it is involved with a transaction (step 40). When a transaction completes (step 42), the Transaction Manager invokes a method (operation) on the Synchronization object (step 44). Upon the invocation of this method, the J2EE RI performs the necessary container state clean up for this transaction (step 46). Each Transaction Manager knows when a transaction is being completed, since it is in communication with all other Transaction Managers. Thus, via a Synchronization object, distributed state clean up in the containers can be performed, without adding additional code or complexity.

[0025] In further detail, when a container creates a system state particular to a transaction, the container attempts to register a Synchronization object with its own Transaction Manager. Since each container may have many states for a single transaction, only one Synchronization object is registered per transaction. It is not necessary, or efficient, to keep registering new Synchronization object for the same transaction. A separate data structure may be used to mark that a particular transaction has already been registered, in order to avoid registering multiple objects for the same transaction.

[0026] In a standard CORBA Synchronization Interface, two operations are defined:

[0027] before_completion

[0028] This operation is invoked prior to the start of the two-phase commit protocol and ensures that any state data that must be made persistent (i.e. saved) is made available to the necessary resource.

[0029] after_completion

[0030] This operation is invoked after all the commit or rollback responses have been received, and the current status of the transaction is provided as input.

[0031] A similar method is defined by the JTA specification, and its operation is similar to that defined by the CORBA standard.

[0032] In the present invention, the before_completion method is called right before a transaction is completed, but basically does not perform any function for the present mechanism. However, an application developer may decide to use this function to perform some preliminary clean up tasks, if relevant. The after_completion method is called immediately after a transaction has completed. The after_completion method triggers a clean up operation in each container affiliated with the transaction. FIG. 1 illustrates the syntax of these operations. The object which implements the Synchronization Interface will provide the before_completion and after_completion methods. For the after_completion method, the body of the method should contain code to perform the necessary clean up operation. Since the clean up operation to be performed is unique to each container, a unique routine needs to run in each container to actually perform the clean up. Actual methods to perform the clean up are well known to those skilled in the art, the disclosure of which is beyond the scope of the present invention.

[0033] As used herein, the term “method” is well known to those of skill in the art to define a particular computer software construct. So as not to confuse this software term with the normally understood claim term “method,” in the appended claim language the software term “method” is referred to as an “operation.”

[0034] Thus, using a predefined mechanism of the Transaction Manager in a new way, a clean up operation can be performed across multiple containers without requiring additional complexity or overhead. Since the Transaction Manager does not need to have specific knowledge of the container, no modifications are needed to the Transaction Manager. Also, since the Transaction Managers already cooperate among themselves, there is no need to create a whole new communication mechanism, which would add complexity and inefficiency.

[0035] Those skilled in the art will appreciate that various adaptations and modifications of the just-described preferred embodiment can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.