Browse Prior Art Database

Calling CosTransactions::Synchronization Interface when Root Coordinator does not Support these Objects

IP.com Disclosure Number: IPCOM000013013D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-12
Document File: 2 page(s) / 49K

Publishing Venue

IBM

Abstract

There are a number of transaction service standards available today. For example, CORBA's OTS, X/Open's XA, Microsoft's COM/MTS/COM+, Sun's JTS. Most provide the ability for arbitrary pieces of software (that support one or more predefined interface(s) with their associated software contract behaviour) to "register" with the transaction manager as a resource or resource manager. This allows the transaction manager to involve these arbitrary pieces of software in the completion decision of transactions (for example, through a two-phase commit). Thus the transaction service can be integrated with other products such as databases allowing data managed by different products to be updated together.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

  Calling CosTransactions::Synchronization Interface when Root Coordinator does not Support these Objects

There are a number of transaction service standards available today. For example, CORBA's OTS, X/Open's XA, Microsoft's COM/MTS/COM+, Sun's JTS. Most provide the ability for arbitrary pieces of software (that support one or more predefined interface(s) with their associated software contract behaviour) to "register" with the transaction manager as a resource or resource manager. This allows the transaction manager to involve these arbitrary pieces of software in the completion decision of transactions (for example, through a two-phase commit). Thus the transaction service can be integrated with other products such as databases allowing data managed by different products to be updated together.

     This idea can be extended to allow one transaction service to register as a resource or resource manager with another transaction service (for examples, see UK Patent Application GB 2339621A) thus allowing the integration of two discrete transaction trees, each managed by a different transaction manager.

     Some transaction services also provide a synchronization interface (for example CORBA's OTS and Java's JTS). This allows a piece of arbitrary software that implements the synchronization interface to "register" with the transaction service so that it is called once just before the calls to the resources (described above) and once after the calls to the resources when the outcome of the transaction (commit or rollback) is known.

     This synchronization interface is very important because the call before the calls to the resources (CosTransactions::synchronization::before_completion() in OTS) is used to flush cached data to the data store and the one after (CosTransactions::Synchronization::after_completion()) is used to release memory etc used by the application.

     This invention concerns the case where a transaction service that DOES support the synchronization interface is registering as a resource/resourceManager with a transaction service that does NOT support a synchronization interface. Without this invention, the registering transaction service would have to either restructure its support to fit inside the resource call...