XSTM Documentation - Software Transactional Memory

Before being a data replication tool, XSTM is a Software Transactional Memory. Transactional memories are an attempt to simplify concurrent programming and make software more robust.

See a description on Wikipedia: http://en.wikipedia.org/wiki/Software_transactional_memory.

The idea is to use transactions when modifying in-memory structures, like it can be done when using a database. In an object-oriented transactional memory, objects are modified in the context of transactions.

Handling Failures

This simplifies a lot the way developers handle failures and exceptions. It is no more necessary to write code in catch clauses of exceptions to try to bring back the application to a consistent state when an action fails. In an STM, the current transaction is simply aborted and modified objects return to their previous consistent state. Software can be made much more robust with less work.

Multi-Threading

But the main benefit of an STM, particularly now that machines run more and more cores, is when writing a multi-threaded program. Instead of using locks to serialize access to objects, the updates are done in the context of transactions. Transactions are isolated from each other and a transaction can be written as if it was the only one modifying the objects in memory.

Think of this as source control for objects. Let's say threads are developers: Today's concurrent programs are like a team of developers working without source control! Those developers would need to cooperate continuously to not write to the same files at the same time, like in in a concurrent program each thread must take care of not modifying a variable used by another one.

By using a source control solution, each developer can work on his own private view of the source code. When he is done working on this private view, and when he has verified it is tested and correct, the developer can merge it to the shared one. Only then other developers will see the modifications, and they will appear all at once. This way the shared view always jumps from a correct state to another correct state. Transactions enable this model for in memory objects.

As it is the case for databases, transactions are isolated from each other. XSTM fully isolates transactions. Databases call this level of isolation Serializable. This means that when it starts, a transaction takes a complete memory snapshot and runs inside this snapshot. The code running in this transaction does not see modifications done by other transactions' commits so it can be written as if there was no concurrency. Transaction commits are atomic so the objects appear to change all at once or not at all if the commit fails.

Here is an example with two transactions reading and writing concurrently the fields of an object ‘a’. The fields have initially the values: name=”Bob” and points=1.

Various software transactional memory implementations can be found. With XSTM, each transaction keeps track of the fields it reads and writes during its execution. When it commits, transaction 1 updates ‘points’ with value 8. If transaction 2 has read the field before the update, it must not be allowed to commit, otherwise it would increment the old value and override transaction 1. A transaction manager keeps a log of recent object updates. When a transaction commits, it checks all its reads against this log and aborts in case of conflict. The transaction can then be restarted from the beginning.

Transactional memories allow a whole gradation of concurrency. An implementation could try to reduce the number of restarted transactions by blocking reads to fields that have uncommitted writes. At the other end, the strategy could be to allow all transactions to proceed, and restart transactions until they commit. The resulting performance can be better or worse than locking. They allow more concurrency at the expense of more book-keeping and some discarded computations. The important thing is that the burden of concurrency tuning is moved from the developer to the transactional memory implementation, and we can presume a continuous increase in the sophistication of the strategies.

When using our implementation, objects manipulated by transactions must be generated by code generator. Getters and setters on these classes can use data stored in the current transaction. As their code is generated, it is not possible to have logic in the transacted objects, which requires separating state and logic in your application. We also provide transacted versions of come common java collections like Set, List and Map.

Our implementation supports long running transactions and the ability to move them between threads. A thread can do some operations in the context of a transaction, and then switch to another one, in the same way a developer switches to another branch when using a source control solution.

XSTM has been extended so its transactions can be sent between machines. A transaction can this way modify objects on several machines instead of one like other Software Transactional Memory implementations, which enables Object Replication.

Home

For a more in-depth description please check the Software Transactional Memory chapter of our free eBook.