Abstract: A method, system and computer program for dynamically updating code managed by an authorized agent. The method includes executing multiple versions of agent code in system memory. One version of the agent code is executed as an active version and another version of the agent code is executed as an inactive version. Version numbers of the active and inactive versions of the agent code are stored in a reloadable module vector. Client instances previously bound to the inactive version of the agent code are bound to the active version of the agent code after comparing the version numbers of the active version of the agent code and the inactive version of the agent code. A portion of the system memory used by the inactive version of the agent code is deallocated when no client instances are bound to the inactive version of the agent code.

Abstract: A method, system and computer program for dynamically updating code managed by an authorized agent. The method includes executing multiple versions of agent code in system memory. One version of the agent code is executed as an active version and another version of the agent code is executed as an inactive version. Version numbers of the active and inactive versions of the agent code are stored in a reloadable module vector. Client instances previously bound to the inactive version of the agent code are bound to the active version of the agent code after comparing the version numbers of the active version of the agent code and the inactive version of the agent code. A portion of the system memory used by the inactive version of the agent code is deallocated when no client instances are bound to the inactive version of the agent code.

Abstract: A method, system and computer program for dynamically updating code managed by an authorized agent. The method includes executing multiple versions of agent code in system memory. One version of the agent code is executed as an active version and another version of the agent code is executed as an inactive version. Version numbers of the active and inactive versions of the agent code are stored in a reloadable module vector. Client instances previously bound to the inactive version of the agent code are bound to the active version of the agent code after comparing the version numbers of the active version of the agent code and the inactive version of the agent code. A portion of the system memory used by the inactive version of the agent code is deallocated when no client instances are bound to the inactive version of the agent code.

Abstract: A method, system and computer program for dynamically updating code managed by an authorized agent. The method includes executing multiple versions of agent code in system memory. One version of the agent code is executed as an active version and another version of the agent code is executed as an inactive version. Version numbers of the active and inactive versions of the agent code are stored in a reloadable module vector. Client instances previously bound to the inactive version of the agent code are bound to the active version of the agent code after comparing the version numbers of the active version of the agent code and the inactive version of the agent code. A portion of the system memory used by the inactive version of the agent code is deallocated when no client instances are bound to the inactive version of the agent code.

Abstract: One or more transaction managers are automatically selected from a plurality of transaction managers for use in processing a transaction. This selection is based on the types of resources used by the transaction and runtime data of the transaction managers able to support one or more of those resource types. The selection of the one or more transaction managers enables less than all of the transaction managers of an application server to be used in transaction commit processing, thereby improving performance.

Abstract: One or more transaction managers are automatically selected from a plurality of transaction managers for use in processing a transaction. The selection is based on types of resources used by the transaction and supported resource types of the transaction managers. The selection of the one or more transaction managers enables less than all of the transaction managers of an application server to be used in transaction commit processing, thereby improving performance.

Abstract: One or more transaction managers are automatically selected from a plurality of transaction managers for use in processing a transaction. This selection is based on the types of resources used by the transaction and runtime data of the transaction managers able to support one or more of those resource types. The selection of the one or more transaction managers enables less than all of the transaction managers of an application server to be used in transaction commit processing, thereby improving performance.

Abstract: One or more transaction managers are automatically selected from a plurality of transaction managers for use in processing a transaction. The selection is based on types of resources used by the transaction and supported resource types of the transaction managers. The selection of the one or more transaction managers enables less than all of the transaction managers of an application server to be used in transaction commit processing, thereby improving performance.

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.