System and method for supporting resource enlistment synchronization

• US 8,327,375 B2
• Filed: 12/06/2010
• Issued: 12/04/2012
• Est. Priority Date: 02/28/2003
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Somogyi, Alexander J.
• Primary Examiner(s): Truong, Camquy
• Application Number:
  US12/961,282
• Publication Number:
  US 20110078687A1
• Time in Patent Office: 729 Days
• Field of Search: None
• US Class Current: 718/104
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

A system uses a transaction manager for supporting resource enlistment synchronization on an application server with a plurality of threads. This system also includes a plurality of wrapper objects, each of which wrapper object wraps a resource object associated with the application server. Upon receiving a request from a thread to enlist a resource object in a transaction, the transaction manager first checks with a wrapper object that wraps the resource object to see if there is a lock being held on the resource object by another said thread in another said transaction. If there is a lock, the transaction manager allows the thread to wait and signal the thread once the lock is freed by another said thread in another said transaction. Otherwise, the transaction manager grants a lock to the thread and holds the lock until an owner of the thread delists the resource object.

Claims

1. A system for supporting resource enlistment synchronization, comprising:

one or more micro-processors;

an application server with a plurality of threads, running on the one or more micro-processors;

a transaction manager that manages a plurality of transactions, wherein each transaction is associated with at least one said thread, and the transaction manager operates to be associated with each of the plurality of threads;

a plurality of wrapper objects, wherein each wrapper object wraps a resource object of a plurality of resource objects, wherein the transaction manager maintains and communicates with each wrapper object of the plurality of wrapper objects to manage resource object enlistment requests from different said threads associated with different transactions;

wherein the transaction manager maintains an enlistment data structure to manage resource object enlistment for the plurality of transactions, and wherein the enlistment data structure maintains a mapping between the plurality of resource objects and the plurality of transactions;

wherein when the wrapper object receives a delist call from the transaction manager, the wrapper object sends an end call to the resource object to end work performed by the resource object associated with the thread and release the lock on the resource object; and

wherein, upon receiving a request from a thread of the plurality of threads to enlist a resource object of the plurality of resource objects in a transaction, the transaction manager

first checks with a wrapper object that wraps the resource object to see if there is a lock being held on the resource object by another said thread in another said transaction,

if there is a lock, then allows the thread to wait and signal the thread once the lock is freed by the another said thread in the another said transaction,

if there is no lock, then grants a lock to the thread and holds the lock until an owner of the thread delists the resource object, wherein the wrapper object is used to access the resource object for the thread.

2. The system of claim 1, wherein:

the plurality of wrapper objects are periodically processed to remove objects that are unused or no longer active.

3. The system of claim 1, wherein:

each of the plurality of resource objects resides in a server node.

4. The system of claim 1, wherein:

the transaction manager uses a priority method to determine which thread will be granted a lock.

5. The system of claim 1, wherein:

after the thread obtains a lock, the thread uses the wrapper object to initiate work on the resource object.

6. The system of claim 1, wherein:

once the transaction manager enlists the resource object and obtains a lock to the resource object, any attempted enlist from a second thread is blocked.

7. The system of claim 1, wherein:

the wrapper object is periodically garbage collected to clear state and unused locks.

8. A method for supporting resource enlistment synchronization, comprising:

providing an application server with a plurality of threads, running on one or more micro-processors;

managing, via a transaction manager, a plurality of transactions, wherein each transaction is associated with at least one said thread, and the transaction manager operates to be associated with each of the plurality of threads;

wrapping each resource object of a plurality of resource objects with a wrapper object in a plurality of wrapper objects, wherein the transaction manager maintains and communicates with each wrapper object of the plurality of wrapper objects to manage resource object enlistment requests from different said threads associated with different transactions;

maintaining, via the transaction manager, an enlistment data structure to manage resource object enlistment for the plurality of transactions, and wherein the enlistment data structure maintains a mapping between the plurality of resource objects and the plurality of transactions;

sending, via the wrapper object when the wrapper object receives a delist call from the transaction manager, an end call to the resource object to end work performed by the resource object associated with the thread and release the lock on the resource object;

receiving a request from a thread of the plurality of threads to enlist a resource object of the plurality of resource objects in a transaction at the transaction manager;

first checking with a wrapper object of the resource object, via the transaction manager, to see if there is a lock being held on the resource object by another said thread in another said transaction;

if yes, allowing, via the transaction manager, the thread to wait and signaling the thread once the lock is freed by the another said thread in the another said transaction; and

if not, granting, via the transaction manager, a lock to the thread and holding the lock until an owner of the thread delists the resource object, wherein the wrapper object is used to access the resource object for the thread.

9. The method of claim 8, further comprising:

allowing the plurality of wrapper objects to be periodically processed in order to remove objects that are unused or no longer active.

10. The method of claim 8, further comprising:

using a priority method to determine which thread will be granted a lock.

11. The method of claim 8, further comprising:

after obtaining a lock, using, via the thread, the wrapper object to initiate work on the resource object.

12. The method of claim 8, further comprising:

once the transaction manager enlists the resource object and obtains a lock to the resource object, blocking any attempted enlist from a second thread.

13. The method of claim 8, further comprising:

determining, via the transaction manager, whether an application associated with the thread is a specific type of application;

granting, via the transaction manager, the thread a lock only when the application is determined to be the specific type of application.

14. A non-transitory computer-readable storage medium, storing instructions for supporting resource enlistment synchronization, the instructions comprising the steps of:

providing an application server with a plurality of threads, running on one or more micro-processors;

managing, via a transaction manager, a plurality of transactions, wherein each transaction is associated with at least one said thread, and the transaction manager operates to be associated with each of the plurality of threads;

wrapping each resource object of a plurality of resource objects with a wrapper object in a plurality of wrapper objects, wherein the transaction manager maintains and communicates with each wrapper object of the plurality of wrapper objects to manage resource object enlistment requests from different said threads associated with different transactions;

maintaining, via the transaction manager, an enlistment data structure to manage resource object enlistment for the plurality of transactions, and wherein the enlistment data structure maintains a mapping between the plurality of resource objects and the plurality of transactions;

sending, via the wrapper object when the wrapper object receives a delist call from the transaction manager, an end call to the resource object to end work performed by the resource object associated with the thread and release the lock on the resource object;

receiving a request from a thread of the plurality of threads to enlist a resource object of the plurality of resource objects in a transaction at the transaction manager;

first checking with a wrapper object of the resource object, via the transaction manager, to see if there is a lock being held on the resource object by another said thread in another said transaction;

if yes, allowing, via the transaction manager, the thread to wait and signaling the thread once the lock is freed by the another said thread in the another said transaction;

if not, granting, via the transaction manager, a lock to the thread and holding the lock until an owner of the thread delists the resource object, wherein the wrapper object is used to access the resource object for the thread.