Method, system, and storage medium for dynamically reordering resource participation in two-phase commit to heuristically optimize for last-agent optimization

• US 20060136887A1
• Filed: 12/21/2004
• Published: 06/22/2006
• Est. Priority Date: 12/21/2004
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: International Business Machines Corporation
• Inventors: Kaczynski, Timothy D., Sykes, Matthew J., Kinder, Stephen J.
• Granted Patent: US 7,712,096 B2
• Time in Patent Office: Days
• US Class Current: 717/151
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/5038 considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration scheduling strategies G06F9/4881 and subgroups

Abstract

A histogram, or resource status history table, for multiple resources is created and maintained. A transaction or resource manager arranges and/or reorders various resources into a sequence based on the histogram such that read-only resources are prepared first and a sole non-read-only resource need not be prepared, but only committed. The transaction manager heuristically determines the order that resources are driven to achieve last-agent optimization. The histogram is kept related to context, based on runtime and applications context to ensure that usage patterns by context are optimized without the need for the installation to know any usage patterns.

Claims

1. A method for last-agent optimization, comprising:

establishing a connection to each resource in a plurality of resources for an application;

determining a current transactional context;

gathering usage statistics associated with each resource; and

heuristically determining an order of each resource in the current transactional context to achieve last-agent optimization based at least in part on the usage statistics.

2. The method of claim 1, wherein the usage statistics associated with each resource include at least one counter selected from:

a number times this resource has been prepared, a number of times this resource has voted read-only, and a number times this resource failed.

3. The method of claim 2, wherein the usage statistics associated with each resource include a read-only ranking and a fail ranking.

4. The method of claim 3, wherein the read-only ranking and the fail ranking are determined at select intervals.

5. The method of claim 2, further comprising:

retrieving an application identifier associated with the application;

wherein a hash map maps the application identifier to the usage statistics for that application.

6. The method of claim 2, wherein the at least one counter is periodically reset.

7. The method of claim 1, wherein the usage statistics are encapsulated in an object that is inserted into a sorted list.

8. The method of claim 3, further comprising:

driving a prepare on each resource based on the read-only ranking associated with that resource;

enlisting each resource in a list of enlisted resources;

removing a read-only resource from the list of enlisted resources for the current transactional context;

performing last-agent optimization for a single enlisted resource.

9. A system for last-agent optimization, comprising:

a histogram for holding usage statistics and history information for each resource in a plurality of resources; and

a transaction manager for ordering each resource in a current transaction based at least in part on the histogram so that read-only resources are prepared first and a sole non-read-only resource is committed without being prepared.

10. The system of claim 9, wherein the transaction manager heuristically determines the order of each resource in the current transaction to achieve last-agent optimization.

11. A system for last-agent optimization, comprising:

an application server running on a general-purpose computer;

a container hosted on the server;

at least one application running in the container, the application including at least one transaction using a plurality of resources;

a transaction manager on the server for heuristically ordering the resources during a commit phase of a two-phase commit process to achieve last-agent optimization; and

a connection manager on the server for supplying the resources to the application and for enlisting the resources with the transaction manager.

12. The system of claim 11, wherein the transaction manager creates transactional boundaries for the application.

13. The system of claim 12, wherein the transaction manager provides atomic outcomes for the resources enlisted in a transactional boundary.

14. The system of claim 11, wherein the transaction manager orders the resources based on dynamic usage statistics.

15. The system of claim 14, wherein the usage statistics are stored in a hash map.

16. The system of claim 11, wherein the transaction manager orders the resources based on history information.

17. The system of claim 11, wherein the transaction manager orders the resources so that any resource likely to vote read-only in response to a prepare call are placed before other resources.

18. A storage medium storing instructions for performing a method for last-agent optimization, comprising:

storing usage statistics in a histogram;

ordering a plurality of resources in a current transactional context using the histogram to achieve last-agent optimization; and

adjusting the ordering autonomically to changes in usage.