Optimistic Transactions

Optimistic Transaction change the semantic of a commit. In normal databases a commit is an atomic operation, that is guaranteed to make all changes and return or make no changes at all and fail (ACID).

An Optimistic Transaction is also atomic, but does not guarantee the execution of the changes upon return. Instead a callback is used to indicate, wether the commit was successfull or has failed.

What is the use of this? Sieben Geisslein allows to commit transactions in the client cache. Once the transaction is committed in the client cache, the application can continue working on the new state. If the transaction succeeds on the server, too, all is fine. Otherwise the effect of the transaction on the client cache (and the effect of all transactions, that have been started after the failing transaction) have to be undone.

This is of course only sensible for transactions, that are highly unlikely to fail.

What does this look like in practice?

Imagine an orthogonal persistent text processor. For each keystroke a new transaction is created. The user does not want to wait for each transaction to be completed on the server (nor does he care, wether the last character has been committed, if the computer crashes). Instead the first transaction is committed in the client cache and after that the commit on the server is started. While this commit operation has not finished, all folowing transactions are committed in the client cache and merged with each other. Once the first transaction is finished, the merged transaction is committed.

If a transaction fails, everything is undone and the user is informed that some of his changes are lost (which is highly unlikely, if he's the only one working on the document).