Systems and methods for maintaining transactional persistence

• US 20040025169A1
• Filed: 05/29/2003
• Published: 02/05/2004
• 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
• Granted Patent: US 6,988,099 B2
• Time in Patent Office: Days
• US Class Current: 719/315
• 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.

This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Claims

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

a transaction manager for beginning and ending the processing of a request, the transaction manager capable of enlisting and modifying any object useful in processing the request;

a locking manager capable of preventing other resources from accessing an object used in processing the request; and

a logging component capable of tracking changes to the object during the processing of the request.

2. A persistence framework according to claim 1, wherein:

said transaction manager is further capable of managing state for the object during processing.

3. A persistence framework according to claim 1, wherein:

said transaction manager is further capable of using the changes tracked by the logging component to undo any modification of the object during processing.

4. A persistence framework according to claim 1, further comprising:

a database forstoring information relating to the request, the database in communication with the transaction manager.

5. A persistence framework according to claim 1, wherein:

said transaction manager can direct said locking manager to allow other resources to access the object once the object is no longer needed to process the request.

6. A persistence framework according to claim 1, further comprising:

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

7. A persistence framework according to claim 6, further comprising:

an additional object representing said trading partner.

8. A persistence framework according to claim 6, wherein:

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

9. A persistence framework according to claim 3, wherein:

said transaction manager is capable of retrying to process the request.

10. A persistence framework according to claim 4, wherein:

said transaction can commit object modifications to the database after processing the request.

11. A persistence framework according to claim 1, wherein:

said locking manager can block access to the object if the object might be used by the transaction manager to process the request.

12. A persistence framework according to claim 1, wherein:

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

13. A persistence framework according to claim 12, wherein:

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

14. A persistence framework according to claim 13, wherein:

said transaction manager keeps a list of enlisted objects.

15. A persistence framework according to claim 14, wherein:

said transaction manager can go through the list of enlisted objects and do an operation for each enlisted object in the list, the operation consisting of one of writing modifications to the database and undoing the modifications.

16. A persistence framework according to claim 1, further comprising:

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

17. A persistence framework according to claim 1, wherein:

said locking manager uses a lock to prevent other resources from accessing an object used in processing the request.

18. A persistence framework according to claim 17, wherein:

said locking manager uses a lock selected from the group consisting of inflated locks and individual locks.

19. A persistence framework according to claim 18, wherein:

said locking manager applies an inflated lock to each object useful in processing the request when said transaction manager begins processing the request.

20. A persistence framework according to claim 19, wherein:

said locking manager attempts to apply a thin lock on each object under the inflated lock that might be used in processing the request.

21. A persistence framework according to claim 1, wherein:

said transaction manager is capable of enlisting and modifying any object selected from the group consisting of trading partners, conversations, databases, external applications, and internal applications.

22. A persistence framework according to claim 1, wherein:

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

23. A persistence framework according to claim 1, further comprising:

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

24. A persistence framework according to claim 1, further comprising:

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

25. A persistence framework according to claim 1, wherein:

said transaction manager initiates a persistent session when beginning to process the request.

26. A persistence framework according to claim 25, wherein:

said transaction manager initiates a persistent session capable of keeping track of enlistable objects.

27. A persistence framework according to claim 26, wherein:

said transaction manager initiates a persistent session capable of housing at least one of a log for an object and a table of objects useful in processing the request.

28. A persistent system for processing a request, comprising:

a transaction manager for beginning and ending the processing of a request, the transaction manager capable of enlisting and modifying any object useful in processing the request;

a locking manager capable of preventing other resources from accessing an object used in processing the request;

a logging component capable of tracking changes to the object during the processing of the request;

a database for storing any modifications to the object during the processing of the request, the modifications stored to the database after the request has been processed; and

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

29. A method for persistently processing a request, comprising:

initiating a transaction to process a request using a transaction manager;

enlisting any object useful in processing the request;

locking any object enlisted by the transaction manager;

modifying the object in order to process the request; and

logging the modifications to the object.

30. A method according to claim 29, further comprising:

storing any modifications to the object during the processing of the request to a database after the request has been processed.

31. A method according to claim 29, further comprising:

sending the request to a message queue after processing the request.

32. A method according to claim 29, further comprising:

committing the transaction if the request is successfully processed.

33. A method according to claim 29, further comprising:

undoing any logged modifications to the object if the request is not successfully processed.

34. A method according to claim 29, further comprising:

unlocking any locked object after the request is processed.

35. A computer-readable medium, comprising:

means for initiating a transaction to process a request using a transaction manager;

means for enlisting any object useful in processing the request;

means for locking any object enlisted by the transaction manager;

means for modifying the object in order to process the request; and

means for logging the modifications to the object.

36. A computer program product for execution by a server computer for persistently processing a request, comprising:

computer code to initiate a transaction to process a request using a transaction manager;

computer code to enlist any object useful in processing the request;

computer code to lock any object enlisted by the transaction manager;

computer code to modify the object in order to process the request; and

computer code to log the modifications to the object.

37. A system for persistently processing a request, comprising:

means for initiating a transaction to process a request using a transaction manager;

means for enlisting any object useful in processing the request;

means for locking any object enlisted by the transaction manager;

means for modifying the object in order to process the request; and

means for logging the modifications to the object.

38. A computer system comprising:

a processor;

object code executed by said processor, said object code configured to;

initiate a transaction to process a request using a transaction manager;

enlist any object useful in processing the request;

lock any object enlisted by the transaction manager;

modify the object in order to process the request; and

log the modifications to the object.