One major part of the Transaction Component are a set of wrappers that allow to add transactional control
to any kind of map implemening the java.util.Map
interface. Transactional control refers
to the procedure that you start a transaction do a number of statements and finally decide to either
commit the changes, i.e. make them permanent, or rather roll back the transaction by discarding all your changes.
As an example imagine a client application where you do complex stuff (maybe
talking to one or more servers) and the user is allowed to cancel the
whole operation. Or it might be needed to be canceled because of errors that occur in the middle of the whole request.
Now image all the results have been stored in a transactional map and you
simply do a rollback on errors and a commit upon success.
The whole thing gets a bit more complicated when more than one transaction is executed on a map at the same time.
In this case these transactions are running concurrently.
Problems that might occur with concurrent transaction are diverse and implementations differ in how much
spurious phenomena can be observed. Here is a survey of the
most common concurrency problems described in the scenario of authors working on documents.
Which phenomenon can occur with which map wrapper implementation can be found in
this chart. This is a
great
more general article about different isolations.
If none of
the known phenomena is observable - which of course is the best you can get - a transaction is called serializable.
The origin of this term comes from a differet, but equivalent definition. This
definition switches the perspective from local phenomena observed inside
transactions to global one, more specific global corretctness. If a set of
transactions are executed
concurrently and there is a strictly sequential execution schedule of those transactions that leaves the
map in the same state as the concurrent one those transactions are called
serializable.