Unconventional transactions

1. Unconventional transactions Jyrki Nummenmaa http://www.cs.uta.fi/~jyrki/ jyrki@cs.uta.fi

2. 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.

3. 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

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. 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.

12. 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.

13. 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.

14. 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.

15. Problems to solve with TIP-like solutions • Security • Trust • Denial-of-service attacks • Recovery, when the protocol fouls up.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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?

21. 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.

22. 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.