Transaction Manager with ICE

ngambek2003

I've seen some threads in this forum about the lack of support for a Transaction Manager in ICE.

I'm wondering if there's been any change with that or if there's a plan to have any kind of support for distributed transactions.

If not what would you recommend doing/using in conjunction with ICE to handle distributed transactions?

Thanks
Budyanto

bernard

Hi Budyanto,

There is no ongoing development in this area - as always, it's a question of commercial demand.

The first question is what are you trying to achieve?

If you are looking to control a transaction in a server from a remote Ice client, this is fairly easy to do, for example by adding your own "transaction-id" Ice context to the requests that you want to run within that transaction.

If you are looking for full distributed transactions, with a transaction manager that coordinates the completion of several participants, then you first need a good transaction manager (with support for 2 phase commits); the best one probably depends on your environment (Windows, Linux, .NET, Java ...). Then you may want to pass the messages exchanged by this transaction manager and the transaction participants (initiator, resources) through Ice.

Best regards,
Bernard

ngambek2003

I'm trying to find a solution for the 2nd case.

I have 2 ice services that need to persist things to a database and I want to make sure that they are atomic.

Can you elaborate on this a little more?

Then you may want to pass the messages exchanged by this transaction manager and the transaction participants (initiator, resources) through Ice.

Thanks

bernard

In your distributed transaction environment, messages will be exchanged between different entities, namely:
- the transaction originator, that starts and later commits the transaction
- the transaction manager/factory that manages the completion of the transaction (two phase commit protocol, persistent logging, recovery...)
- resources such as databases that participate in the transaction

The transaction manager/factory is the most critical and complex component: it has to be able to recover from many different error scenario, and I don't think "writing your own 2PC transaction manager" is a reasonable proposition. So you should select an existing transaction manager.

It's very likely this transaction manager will come with some form of distributed communications mechanism, such as DCE, CORBA, or SOAP. You may be able to use DCE/CORBA/SOAP for transaction-related messages, and Ice for everything else, but this would probably become complex and hard to maintain.

A better approach is to "adapt" your transaction manager messages to Ice: write an Ice server that translates messages to/from your transaction manager into Ice messages. A secondary task would be to integrate your resources with this Ice-wrapped transaction manager; this code would "enroll" your database transaction in the distributed transaction (using XA, JTA, the equivalent .NET API, or the native API of your database system).

We could of course help you with such an integration and even the selection of the transaction manager. Please contact sales@zeroc.com for more information.

Best regards,
Bernard

ngambek2003

Bernard,

Thanks for the detailed response. I have come to the same conclusion. I was looking at JBoss Transaction Service (JBossTS) and they use CORBA as their distributed communication mechanism. So if the services use CORBA, then JBossTS can be used easily - passing of transaction context can be done transparently.

However, since ICE doesn't use CORBA, some form of "adaptation" needs to be done somewhere.

Again thanks for the detailed response. We'll take your suggestion into consideration.