Systems and methods for maintaining transactional persistence

• US 6,988,099 B2
• Filed: 05/29/2003
• Issued: 01/17/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 AL
• Application Number:
  US10/447,778
• Publication Number:
  US 20040025169A1
• Time in Patent Office: 964 Days
• Field of Search: 707/8, 707/10, 707/103.R, 707/104.1, 707/202, 719/316, 711/114, 711/119, 717/1, 717/11, 717/121
• US Class Current: 1/1
• 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 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, wherein said transaction manager tracks any logs maintained by the logging mechanism in processing the request and said transaction manger can use the logs to undo any modifications made to any objects in processing the requests and wherein said transaction manager keeps a list of enlisted objects, 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.

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 3, wherein:

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

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

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

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

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

7. 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.

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

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

9. A persistence framework according to claim 8, further comprising:

an additional object representing said trading partner.

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

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

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, further comprising:

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

13. 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.

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

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

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

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

16. A persistence framework according to claim 15, 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.

17. 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.

18. 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.

19. 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.

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

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

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

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

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

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

23. A persistence framework according to claim 21, 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.

24. The persistence framework of claim 1 wherein the operation consists of writing the modifications to the database if the request succeeds or undoing the modifications if the request fails.

25. 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, wherein;

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

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

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

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

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

28. 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, 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.

29. A persistence framework according to claim 28, wherein:

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

30. A persistence framework according to claim 28, 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.

31. A persistence framework according to claim 30, wherein:

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

32. A persistence framework according to claim 28, further comprising:

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

33. A persistence framework according to claim 32, wherein:

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

34. A persistence framework according to claim 28, 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.

35. A persistence framework according to claim 28, further comprising:

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

36. A persistence framework according to claim 35, further comprising:

an additional object representing said trading partner.

37. A persistence framework according to claim 35, wherein:

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

38. A persistence framework according to claim 28, wherein:

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

39. A persistence framework according to claim 28, wherein:

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

40. A persistence framework according to claim 39, wherein:

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

41. A persistence framework according to claim 40, wherein:

said transaction manager keeps a list of enlisted objects.

42. A persistence framework according to claim 41, 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.

43. A persistence framework according to claim 28, further comprising:

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

44. A persistence framework according to claim 28, wherein:

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

45. A persistence framework according to claim 44, wherein:

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

46. A persistence framework according to claim 45, wherein:

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

47. A persistence framework according to claim 46, 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.

48. A persistence framework according to claim 28, wherein:

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

49. A persistence framework according to claim 28, wherein:

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

50. A persistence framework according to claim 28, comprising:

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

51. A persistence framework according to claim 28, further comprising:

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

52. A persistence framework according to claim 28, wherein:

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

53. A persistence framework according to claim 52, wherein:

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

54. A persistence framework according to claim 53, 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.

55. 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, wherein;

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

56. A persistence framework according to claim 55, wherein:

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

57. A persistence framework according to claim 56, 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.

58. 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.

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

a transaction manager adapted to process requests, the transaction manager capable of enlisting and modifying objects useful in processing the request;

a locking manager adapted to prevent other resources from accessing an object used in processing the request; and

a logging component adapted to track changes to the object during the processing of the request, wherein said transaction manager is adapted to track any logs maintained by the logging mechanism in processing the request and wherein the transaction manager keeps a list of enlisted objects, wherein the transaction manager is adapted to go through the list of enlisted objects and do an operation for each enlisted object in the list, the operation consisting of one of the group of writing modifications to the database and undoing the modifications.

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

a transaction manager adapted to process requests, the transaction manager capable of enlisting and modifying objects useful in processing the request;

a locking manager adapted to prevent other resources from accessing an object used in processing the request; and

a logging component adapted to track changes to the object during the processing of the request, wherein said transaction manager is adapted to track any logs maintained by the logging mechanism in processing the request and wherein the transaction manager keeps a list of enlisted objects, wherein the transaction manager is adapted to go through the list of enlisted objects and do an operation for each enlisted object in the list, the operation being writing the modifications to the database if the request succeeds or undoing the modifications if the request fails.

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

a transaction manager adapted to process requests, the transaction manager capable of enlisting and modifying objects useful in processing the request;

a locking manager adapted to prevent other resources from accessing an object used in processing the request; and

a logging component adapted to track changes to the object during the processing of the request, wherein;

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

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

a transaction manager adapted to process requests, the transaction manager capable of enlisting and modifying objects useful in processing the request;

a locking manager adapted to prevent other resources from accessing an object used in processing the request; and

a logging component adapted to track changes to the object during the processing of the request, wherein;

said transaction manager is capable of enlisting and modifying objects including trading partner objects and conversation objects.