Technique for managing enterprise JavaBeans (™) which are the target of multiple concurrent and/or nested transactions

• US 6,298,478 B1
• Filed: 12/31/1998
• Issued: 10/02/2001
• Est. Priority Date: 12/31/1998
• Status: Expired due to Term

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Nally, Martin P., Salo, Timo J., Rich, Lawrence Scott
• Primary Examiner(s): Chaki, Kakali
• Assistant Examiner(s): Vo, Ted T.
• Application Number:
  US09/223,986
• Time in Patent Office: 1,006 Days
• Field of Search: 717/6, 717/2, 717/3, 717/11
• US Class Current: 717/170
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/54 Interprogram communication

Abstract

A technique for providing a transaction management subsystem for an enterprise computing environment in which multiple concurrent and/or nested transactions may access the same Enterprise JavaBeans (EJBs) simultaneously. The transaction management subsystem provides a view for each transaction which includes an independent version of an EJB'"'"'s business logic and its instance data. When an application or application user has made modifications to an EJB version and requests to commit the modifications, a determination is first made as to whether committing the modifications will result in an unacceptable data conflict with other versions of the same EJB. If no unacceptable data conflict will occur, and after resolution of those conflicts that can be resolved, the modifications are committed. The management subsystem also supports nested transactions, where each subtransaction may have an independent view of an EJB. Subtransactions may commit or roll back independently. Changes made by a transaction are represented using a tree structure that is internally managed by the application.

Claims

1. Computer-readable media for managing Enterprise JavaBeans (EJBs) and maintaining an integrity of said EJBs in systems which permit access to said EJBs by multiple concurrent and/or nested transactions, said transactions being comprised of one or more subtransactions and said EJBs being comprised of a first instance data part, said computer-readable media embodying computer readable code comprising:

a subprocess for creating an independent version of a selected EJB in a view associated with each of a plurality of subtransactions, said version comprising a business logic part, a second instance data part, and version status data, wherein said subprocess for creating further comprises initializing said second instance data part from said first instance data part;

a subprocess for temporarily making one or more modifications to said first instance data part of said selected EJB, said modifications requested by a selected one of said subtransactions, by making said modifications to said corresponding second instance data part in said independent version in said associated view of said selected subtransaction;

a subprocess for committing said modifications upon a commit request; and

a subprocess for performing a rollback of said modifications upon a rollback request.

2. Computer readable code according to claim 1, wherein said subprocess for committing further comprises:

a subprocess for use when said subtransaction is not a top-level transaction in a transaction tree, comprising;

a subprocess for attempting to merge said modifications to a parent of said subtransaction upon said request to commit said modifications;

a subprocess for cancelling said commit request if said subprocess for attempting detects one or more unresolvable data conflicts with one or more separate modifications made to said selected EJB, wherein said separate modifications are stored by said parent in one of said independent views, said one view being associated with said parent;

a subprocess for performing said merge of said modifications to said independent view associated with said parent if said subprocess for attempting does not detect any of said unresolvable data conflicts; and

a subprocess for committing said merged modifications to said independent view associated with said parent; and

a subprocess for use when said subtransaction is said top-level transaction in said transaction tree, comprising;

a subprocess for committing said modifications with a corresponding EJB in a persistent store;

a subprocess for merging said modifications to a global transaction if said subprocess for committing does not detect an error condition; and

a subprocess for discarding said top-level transaction and any subtransactions related to said top-level transaction in said transaction tree.

3. Computer readable code according to claim 1, wherein said subprocess for committing further comprises:

a subprocess for use when said subtransaction is not a top-level transaction in a transaction tree, comprising;

a subprocess for attempting to merge said modifications to a parent of said subtransaction upon a request to commit said modifications;

a subprocess for cancelling said commit request if said subprocess for attempting detects one or more unresolvable data conflicts with one or more separate modifications made to said selected EJB, wherein said separate modifications are stored by said parent in said independent view associated with said parent;

a subprocess for performing said merge of said modifications to said independent view associated with said parent if said subprocess for attempting does not detect any of said unresolvable data conflicts; and

a subprocess for committing said merged modifications to said independent view associated with said parent; and

a subprocess for use when said subtransaction is said top-level transaction in said transaction tree, comprising;

a subprocess for committing said modifications with a corresponding EJB in a persistent store; and

a subprocess for discarding said top-level transaction and any subtransactions related to said top-level transaction in said transaction tree.

4. Computer readable code according to claim 2, wherein said subprocess for attempting further comprises invoking application-specific logic to determine when said separate modifications indicate that one of said unresolvable data conflicts is found and said subprocess for merging further comprises invoking application-specific logic to resolve any resolvable data conflicts.

5. Computer readable code according to claim 3, wherein said subprocess for attempting further comprises invoking application-specific logic to determine when said separate modifications indicate that one of said unresolvable data conflicts is found and said subprocess for merging further comprises invoking application-specific logic to resolve any resolvable data conflicts.

6. Computer readable code according to claim 2, wherein said transaction tree represents a plurality of subtransactions in a nested transaction.

7. Computer readable code according to claim 3, wherein said transaction tree represents a plurality of subtransactions in a nested transaction.

8. A system for managing transactions in a networking environment which permits multiple transactions to access one Enterprise JavaBean (EJB) at a same time, comprising:

means for providing each of said transactions with a view which includes an independent version of said EJB which the transaction or a related transaction is working with, wherein the independent version has a business logic part, an instance data part, and a version status part, wherein said instance data part is initially copied from a corresponding part in a persistent store containing said EJB;

means for determining if an unresolvable data conflict will occur between versions of said EJB in different transactions when one of the transactions is requested to be committed;

means for canceling the commit if one or more unresolvable data conflicts will occur;

means for merging the versions of said EJB if none of said unresolvable data conflicts will occur; and

means for committing the merged versions.

9. The system according to claim 8, wherein:

said determining means determines that no unresolvable data conflict will occur if one of an EJB version from a child transaction and a parent transaction which are to be merged has not been modified or where both of the EJB versions have been modified from the child transaction and the parent transaction, logic is applied that determines that the EJB versions can be successfully merged; and

wherein said merging means further comprises means for invoking application-specific logic to resolve any resolvable data conflicts.