It is not necessary to understand this notion to use XSTM, but if you are interested in its internal workings, here it is. 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 objects in memory, like it can be done using a database. In an object oriented transactional memory, in case of failure or exception, the objects return to their previous state. In a multithreaded program, instead of using locks to serialize access to objects, the updates are done concurrently in the context of transactions.

To apprehend the benefits, think of threads as being developers. Todays concurent programs are like a team of developers working without source control! They would need to cooperate continuously to not write to the same files at the same time. In a program, each thread must take care of not modifying a variable used by another one. With source control, each developer can work on his own private view of the source code. Transactions enable this model for in memory objects.

As it is the case for databases, transactions are isolated and the code running in their context can be written as if there was no concurrency. Transaction commits are also 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.