Abstract: A system and method for allowing transaction callback processing to be synchronized or to take effect prior to completion of a transaction or message. Additional objects that will take part in the transaction can be registered on any server during the transaction's active phase. After the commit function is called, each synchronization object is called during the transaction preprepare processing. A synchronization object can register another object, call a server not previously involved in the transaction, or involve a new resource in the transaction. The effect is to provide a circular pattern of request passing that allows additional resources to be added into the loop prior to commit.

Abstract: A transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: A system and method for allowing transaction callback processing to be synchronized or to take effect prior to completion of a transaction or message. Additional objects that will take part in the transaction can be registered on any server during the transaction's active phase. After the commit function is called, each synchronization object is called during the transaction preprepare processing. A synchronization object can register another object, call a server not previously involved in the transaction, or involve a new resource in the transaction. The effect is to provide a circular pattern of request passing that allows additional resources to be added into the loop prior to commit.

Abstract: The invention provides a mechanism for allowing a transaction callback processing to be synchronized or to take effect prior to completion of a transaction or message. Additional Synchronization objects that will take part in the transaction can be registered on any server during the transaction's active phase. After the commit function is called, each Synchronization object is called during the transaction preprepare processing. A Synchronization object can register another Synchronized object, call a server not previously involved in the transaction, or involve a new XA resource in the transaction. The effect is to provide a circular pattern of request passing that allows additional resources to be added into the loop prior to commit.

Abstract: A transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Failback operation may occur whether recovery is completed or not. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers.

Abstract: A transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: The invention provides a mechanism for use with a transaction processing system that allows a transaction to include a number of associated transaction properties. Transaction properties in turn allow named objects to be associated with a transaction. Transaction properties are available wherever the transaction is active. They can be used as a form of attachment or out-of-band communication mechanism as a transaction flows to various servers in a distributed system, or between different software modules within a single system.

Abstract: A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Failback operation may occur whether recovery is completed or not. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers.

Abstract: The invention provides a transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Failback operation may occur whether recovery is completed or not. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers.

Abstract: A transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: In one embodiment, application versioning and production redeployment support is designed to handle application upgrade needs in mission-critical, production environments. With multiple application versions, application availability to both existing and new clients is not interrupted during the process of application upgrade. It also provides the ability to test a new application version before opening it to general public as well as the ability to roll back to previous safe versions if there are any errors in the currently active version. Clients see consistent application versions, irrespective and transparent of all failure conditions, including admin or managed server restarts and/or failover. Administrators can monitor and manage application versions easily with the management Console.

Abstract: In one embodiment, application versioning and production redeployment support is designed to handle application upgrade needs in mission-critical, production environments. With multiple application versions, application availability to both existing and new clients is not interrupted during the process of application upgrade. It also provides the ability to test a new application version before opening it to general public as well as the ability to roll back to previous safe versions if there are any errors in the currently active version. Clients see consistent application versions, irrespective and transparent of all failure conditions, including admin or managed server restarts and/or failover. Administrators can monitor and manage application versions easily with the management Console.

Abstract: The invention provides a mechanism for use with a transaction processing system that allows a transaction to include a number of associated transaction properties. Transaction properties in turn allow named objects to be associated with a transaction. Transaction properties are available wherever the transaction is active. They can be used as a form of attachment or out-of-band communication mechanism as a transaction flows to various servers in a distributed system, or between different software modules within a single system.

Abstract: The invention provides a transaction service that allows lightweight clients to perform a delegated commit at a server. This process allows lightweight clients to begin and terminate transactions, while the actual responsibility for transaction commit processing is delegated to a commit server and transaction manager running on the machine hosting the server. Client applications do not require a local transaction server. The commit server can be selected from the plurality of servers accessible to the client, and is responsible for committing the transaction to other (participating) servers taking part in the transaction.

Abstract: The invention provides a mechanism for allowing a transaction callback processing to be synchronized or to take effect prior to completion of a transaction or message. Additional Synchronization objects that will take part in the transaction can be registered on any server during the transaction's active phase. After the commit function is called, each Synchronization object is called during the transaction preprepare processing. A Synchronization object can register another Synchronized object, call a server not previously involved in the transaction, or involve a new XA resource in the transaction. The effect is to provide a circular pattern of request passing that allows additional resources to be added into the loop prior to commit.

Abstract: A uniform object model integrates objects defined by foreign type systems into a single integrated object oriented system. The type system for the integrated object oriented system supports a superset of features from foreign object systems. The uniform object model approach converts foreign objects into uniform object model objects defined by the integrated type system and layers onto the uniform object model objects additional members supported by the integrated type system. Adapters integrate foreign objects and data sources into the integrated object oriented system by implementing foreign objects as full fledged objects of the system. The foreign object adapters are bi-directional such that objects, registered in the system, are exposed to foreign object systems. During run time, clients obtain a connection to the data source adapter, which supports the target data source, to execute transactions in the target data source.