Why Pessimistic Transactions Aren’t Practical

Share the article!

I wrote a while ago why locking can’t be abstracted away, that’s something not too obvious for many. However, here’s a few thoughts about the loosely coupled nature of alternative transaction mechanisms.

Conventional transactions, usually associated with pessimistic locking, support ACID. That is Atomicity (all or nothing), Consistency (consistent state changes), Isolation (intermediate effects aren’t visible) and Durabilitity (effects are persistent). However loosely coupled systems some of these requirements may simply not be practical.

Isolation for example may not be enforceable if transaction may last for hours or even worse days or years. Atomicity may be difficult in that certain parts of a transaction may not be so easilly rolledback.

The two phase commit protocol can be summarizes as a request for commitment, an acknowledgement in the form of a promise by all participants (i.e. a consensus, albeit a unanimous one) followed by a subsequent execution. Judge asks jury if they’ve got a unanimous verdict if so, then an execution can proceed. However, what if you can’t get universal agreement within the an allocated time or what if the origninator changes his mind and a participant can’t rollback a commitment without financial consequences (e.g. the typical hotel reservation)?

The other problem with two phase commit is that, how a participant handles its resources and delivers on its promises may differ in a multiple party scenario. The ramifications of promising a resource and its rollback can only in general be supported by using a compensation that is tied to the participants business logic.

Now if we took a look how an optimistic transaction works in general. An optimistic transaction doesn’t performing any reservation of a resource, that is it doesn’t use a lock. Rather than trying to ensure consistency among multiple requestors as they contend for a resource, optimistic locking gives all requestors copies with the hope that it can reconcile the inconsistencies at a later time.

How the reconciliation is done (also known as a merge) can be automatic if its found that there are no conflicts withing the logical internal boundaries of a resource. However if there’s a conflict, then a merging algorithm needs to be chosen. That merging algorithm is of course dependent on the semantics of the resource and therefore equivalent to a compensation in the sense that its tied to business logic.

However, there are several differences that make it more loosely coupled. The first is that the point in time when a conflict is resolved can actually be arbitrary. That is, you can resolve conflict the first time you see it occur, or you can resolve it when any number of participants have responded. Resolving conflict is a natural feature of these protocols and fits nicely from the context of providing compensation.

Afterall, a compensation may not necessarily involve just the originator of a request and the participant. It may in fact be bound by multiple parties through a complex contract. So like a contract, every participant gets a copy, however depending on the style of a contract, changes may be made on each one to result in a result that may either nullify it or result in compensation.

So its just interesting that consensus is usually achieved via some contract and how this ties back to the loosely coupled nature of optimistic transactions. See, the participants of this world walk at different speeds, it’s important for the systems designers to take this fundamental fact into account.


Share the article!