Distributed Transaction Management, Fall 2002 Unconventional transactions Jyrki Nummenmaa jyrki/ [email protected]

Distributed Transaction Management, Fall 2002

Unconventional transactions

Jyrki Nummenmaa http://www.cs.uta.fi/~jyrki/

[email protected]


Motivation

Transactions managing design data can be very long, as the design progresses slowly.

Business transactions may progress slowly, as they may involve exchange of electronic documents between companies.


Traditional TP for long txns?

Traditional transaction processing may not be appropriate, as items may get locked for too long, global commit or rollback may not be feasible,

and global recovery may not be feasible


Hierarchical transactions

One approach to solving these problems is to divide the transactions into parts hierarchically. Each part will be committed separately. The hierarhical division is, of course,

fundamentally different from just distribution. The transactions in the hierarchy may be

distributed or centralised.


Hierarchical transaction commit

Principle: a transaction in the hierarchy can be committed, when all of its sub-parts have been committed.

Sub-parts are committed as their work is done. This way, locking will be less problematic, as

locks are released as part-transactions commit.


Problematic rollback

If all goes well (all transactions in the hierarhcy commit)

What happens, if there is a need to rollback, and some part-transactions have already been committed?

We need some way to manage with the already committed part-transactions.


Simple rollback is not possible

Suppose that one part-transaction in the hierarchy needs to rollback, while some other part-transaction has already committed.

Simple rollback does not necessarily do, as committed transactions may have some side-effects.


Restarting the part-transaction

If it is possible to re-start the initially failed part-transaction, then the problem of rolling back the already committed disappears.

This may not be always possible, but should, of course, be done whenever possible.


Compensating transactions

One possibility to roll back an already committed (part-)transaction is to use a compensating transaction.

A compensating transaction somehow negates the effects of the original transaction.


What cannot be compensated

Examples: money given from a cashline machine a money transfer to a bank account an access given and already used an electronic document/program

downloaded or sent


The previous slide was not exactly true...

Although the compensation can not be done automatically, there may be ways to do it through electronic or manual document or message exhange.

This is particularly true for business-to-business transactions between trusted partners.


Alternative continuations

In some application fields it may be possible to continue the transaction in some other way, if the first way does not work out, without having to roll back the all or some parts of the transaction.

If some part of a business transaction leads to failure, there may be another equally possible way to do it.


Technology for distributed txn management

Java2EE and Microsoft have their own technologies available for middleware implementation.

You can use an API to make a participant and use the coordinator provided by J2EE/Microsoft.

TIP is yet another possibility – but has not been a success.


Why this is not enough?

These technologies do not support the hierarchical transaction management.

The companies like to have the control over their transactions.

TIP supports heterogeneous environments, but is vulnerable to failure and attacks.


Problems to solve with TIP-like solutions

Security Trust Denial-of-service attacks Recovery, when the protocol fouls up.


TIP – denial of service attacks

PULL-based: A rogue company that knows the transaction ID

sends a PULL to a site then close the connection.

PUSH-based Flood a sites with PUSHes so that it cannot service

legitimate requests.

If a site loses its connection to its superior, the rogue sites sends it a RECONNECT command and tells it the wrong result of the commit.


TIP – repudiation

Interaction of 2PC and authenticated protocol messages

The semantics of the authenticated messages only apply if the txn is committed.

If a message from A to B is part of a 2PC protocol, then B’s possession of the digital signature proves nothing.

A can claim: Yes, that was sent, but the action was rolled back.

B must prove that the action was committed. B must also prove that the message was part of that txn.


Problems to solve with TIP-like solutions : security

It is possible to use Secure-HTTP/SSL/TLS with encryption and end-to-end authentication

This works for just security, but developments for trust and denial-of-service attack management will probably require changes here.


Problems to solve with TIP-like solutions : trust

If just about any company may participate in the transactions, then trust for the good will of the company is required. This, in particular has to do with denial-of-service attacks and non-repudiation.

Even if participation is limited to companies, whose good will we trust, we still need to trust their implementations.


Problems to solve with TIP-like solutions : ”manual” recovery

If the protocol fails and manual recover is necessary, then how will this be done in inter-company transactions?

In other words, operator intervention is needed when the commit protocol fouls up - how will this work on the Internet?


Brokerage companies / electronic marketplaces

It would seem from above that there is demand for electronic marketplaces or brokerage companies through which business is done.

Some such marketplaces have been implemented – they have been expensive and there is no evidence as yet that they will meet the expectations.


Current trend

Companies write their complicated business transactions in a way in which they manage their own transactions themselves instead of giving the control outside.

This means that in case of troublesome rollback situations, they have to use compensating – but not necessarily 100% automatic – transactions.

Documents

Distributed Transaction Management, Fall 2002 Unconventional transactions Jyrki Nummenmaa jyrki/ [email protected]