Calling CosTransactions::Synchronization Interface when Root Coordinator does not Support these Objects
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-12
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.