Systems and methods for maintaining transactional persistence

• US 7,117,214 B2
• Filed: 02/16/2005
• Issued: 10/03/2006
• Est. Priority Date: 06/27/2002
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: BEA Systems Incorporated (Oracle Corporation)
• Inventors: Dalal, Sanjay, Wiser, David
• Primary Examiner(s): Alam, Shahid
• Application Number:
  US11/059,289
• Publication Number:
  US 20050144170A1
• Time in Patent Office: 594 Days
• Field of Search: 707/9, 707/10, 707/103.R, 707/8, 707/202, 709/218, 709/219, 710/200, 713/167, 713/168, 713/200, 719/310, 711/114, 711/119, 717/1, 717/11, 717/121
• US Class Current: 719/316
• CPC Class Codes: G06F 2209/523 Mode
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms
• CPC Class Codes: Y10S 707/955 Object-oriented
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database
• CPC Class Codes: Y10S 707/99939 Privileged access
• CPC Class Codes: Y10S 707/99944 Object-oriented database structure
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

Messages between trading partners can be processed persistently using a persistence framework, which can include a transaction manager, a locking manager, and a logging mechanism. A transaction manager can initiate a transaction for a request, and can enlist and modify any object or resource useful in processing the request. A locking manager can lock any of these objects, using inflated and/or individual locks, to prevent other resources or transactions from accessing the object during the transaction. A logging component can track any modifications of the object, while a transaction manager can manage state for the object.

Claims

1. A system for providing a persistence framework for processing a request, comprising:

a transaction manager that initiates a transaction for beginning and ending the processing of a request, wherein the transaction manager enlists and modifies objects useful in processing the request;

a locking manager that prevents other resources from accessing an object by first applying an inflated lock to all objects that might be used in processing the request and subsequently applying a thin lock to each individual object that is identified as actually to be used in processing the request; and

a logging component that tracks changes to the object during the processing of the request, wherein a database for storing information relating to the request, the database in communication with the transaction manager.

2. The system of claim 1, wherein:

said transaction manager manages state for the object during processing.

3. The system of claim 1, wherein:

said transaction manager uses the changes tracked by the logging component to undo any modification of the object during processing.

4. The system of claim 3, wherein:

said transaction manager re-tries to process the request upon roll back of the transaction.

5. The system of claim 1, wherein:

said transaction manager directs said locking manager to allow other resources to access the object that has been identified as actually used in processing the request, once the object is no longer needed to process the request.

6. The system of claim 1, further comprising:

at least one trading partner for making a request into the persistence framework.

7. The system of claim 6, further comprising:

an additional object representing said trading partner.

8. The system of claim 6, wherein:

said logging mechanism stores and continually updates the state of the object being processed in-memory.

9. The system of claim 1, wherein:

said transaction commits object modifications to the database after processing the request.

10. The system of claim 1, wherein:

said locking manager releases the inflated lock after obtaining all needed thin locks such that other resources can access the objects that are not actually used in processing the request.

11. The system of claim 1, wherein:

said transaction manager tracks any logs maintained by the logging mechanism in processing the request.

12. The system of claim 11, wherein:

said transaction manger uses the logs to undo any modifications made to any objects in processing the requests.

13. The system of claim 12, wherein:

said transaction manager keeps a list of enlisted objects.

14. The system of claim 1, further comprising:

resource data pertaining to objects that can be enlisted by said transaction manager.

15. The system of claim 1, wherein:

said locking manager releases the inflated lock if the locking manager is unable to place thin locks on all objects actually used to process the transaction.

16. The system of claim 1, wherein:

said transaction manager is running on one of an incoming processing module and an outgoing processing module.

17. The system of claim 1, further comprising:

a messaging queue for receiving the request from said transaction manager after the transaction manager finishes processing the request.

18. The system of claim 1, further comprising:

a database for storing a log maintained by said logging mechanism.

19. A computer implemented method for providing a persistence framework for processing a request, comprising:

initiating the processing of a request, including enlisting and modifying a one or more objects useful in processing the request;

placing an inflated lock on all objects that might be useful in processing the request;

placing a thin lock on each individual object that will actually be employed in processing the request;

releasing the inflated lock after placing the thin lock on each individual object that will be employed in processing such that objects which will not be employed in processing the request can be accessed by other resources; and

tracking changes to the one or more objects used in processing the request during the processing of the request.