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.