Contiguous transactions and notifications

Copyright 2009-2011 © Gabriel Zs. K. Horvath

Contiguous transactions

Up to now atomicity has consisted in ensuring that writes to a number of versioned variables were “performed instantly”. The idea is that there is no observable gap between when the variables involved in the transaction are modified. So we have no gap between writes, but what about gaps between transactions? After a transaction has committed one might need to start a new transaction in the state the previous transaction left it in. One could start a new transaction straightaway, hoping to catch the system in the state the previous transaction left it in. But of course there always a risk that another transaction commits in the meantime and modifies the state of the system before our follow-on transaction starts. A contiguous transaction is one which is guaranteed to see the system in the state its parent transaction put it in.

Notifications

Actions are what transactions do, in our case they are the write operations performed against the system at commit time. These actions represent the difference between the global state of system just before and after the commit phase. Another representation of the delta is the difference between the actual versions. Any of these representations contains all the information which relates the two versions in the variables history; they represent the changes made between the two versions. This is of course not always the case, adding an element to a set which already contains that set doesn’t result in a delta in terms of version. Same thing with a simple value versioned variable if the variable is set to the same value. The actions contain more information than the delta between the versions.

Contiguous transactions become notification transactions by incorporating this delta. These notification transactions have access to the state of the system as it stands after the transaction has committed, and to the delta which brought the system to this state. This makes them great for logging purposes or for duplicating the state of the system, e.g. updating a user interface or other replication purposes.

It is worth noting that in principle the operation which consists of subscribing to notification could or should be made to be gap free. Consider a GUI application which retrieves data from the data store, this will be performed using a read-only transaction. Once this is done, the application will want to update its UI to keep it in sync with the data store. Ideally this should be done by synchronizing the subscription with the read-only transaction, so that the application starts to receive all notifications of changes as soon as the read-only transaction has started. Of course the application could subscribe to the notifications before starting the read-only transaction and filter out any irrelevant notification.