3.3 Transaction Manager Steps
This section describes implementation details. You do not need to read it if you just want to use CloudTran.
The basic operation of the transaction manager is described in the steps later, with reference to this diagram.
3.3.1 Start and Commit|
There can be any number of client nodes, cache nodes and transaction manager nodes.
The cache and transaction manager functions can be in the same JVM or separated, whichever is the easier to manage.
The managers are preferably in a partitioned cache (distributed-scheme), which spreads the transaction management processing load evenly.
The CloudTran isolator is a singleton in this version of CloudTran.
Variations to the order given above are possible. They arise from subtleties of timing, configuration options or
optimizations for particular styles of transactions.
Start Transaction The client applications makes an API call, such as begin() in TopLink Grid, which leads to a transaction being started.
The transaction is identified by a transaction number, and that number is used to route the "start" request to a particular manager.
This manager instance normally coordinates the complete transaction; it may change if the transaction manager cache repartitions.
Write Data When the client writes data as part of a transaction,
this ends up with a put or remove into the cache.
CloudTran wraps this operation and creates a transactional entry in the grid;
in addition to the original data value, the transactional entry records the new value.
If there is already a transaction entry in the grid, the update is denied and the transaction will rollback.
We show just one write operation in the diagram, but of course there can be any number of them.
Copy Data The data is copied to the transaction manager responsible for the transaction.
In normal usage, this means that, when the time comes, all the information for a transaction is located in one node,
and this can be set to the database(s) using a native (connection-based) transaction at the database rather
than an XA transaction. In unusual cases, such as the client failing, the
transaction manager can time out the transaction on its own initiative;
in this case, it knows all the transactional entries that must be rolled back.
Commit The client issues commit(), which results in the call to the transaction manager to commit the transaction.
This results in steps 4-6 being executed by the manager before it returns, in step 7.
Get Transaction Ordering The first step in the commit process is the manager gets the 'order number' and 'OKToPersist' from the isolator.
The OKToPersist is used by the persistence subsystem to ensure that this transaction - which, say, has an update to Customer 15's data -
does not get written to the database before a previous transaction which changes customer 15.
If such a previous transaction is still being persisted, then the later transaction must wait until the previous one has persisted.
The isolator is a singleton - there is only one operational instance, the primary.
The isolator therefore is a potential bottleneck. In practice it isn't, because the isolator handles 100,000-200,000 rows per second, per core -
so reaching into millions of rows per second on high-core machines.
Log The Transaction This is an optional step. It writes the transaction to a local hard disk or SSD device.
In a cloud environment, this would need to be a disk-as-a-service like Elastic Block Storage, if stored data is transaction.
The transaction log is used to recreate the database writes, but only if there is a catastrophic system failure.
Commit To In-Memory The manager converts all the transactional entries into the new values, without a transactional lock,
across all nodes involved in the transaction.
(In the case of a rollback/abort, this step removes the transactional information from the entry and converts it back to the original value.)
These entries can now be used in other transactions. The "convert" instructions are sent in parallel with each other and with the
Note Commit Record that the transaction is committed, by writing into the manager's cache (which should be backed up).
Return to app The commit operation in the transaction manager finishes and returns to the application.
Persist When all objects in the transaction are free to persist (because no other transactions are still persisting
one or more of the objects), the information is sent to the database(s).
If a database is unavailable, CloudTran keeps retrying: once a transaction is committed,
CloudTran makes sure it is also persisted.
If there are multiple databases, this is done independently to each database - in other words, without using an XA transaction.
This approach optimises performance, but users of down-stream data should be aware that the databases can get out of step.
A transaction can be rolled back at any point between (a) the
start() and (b)
being actioned at the manager.
The rollback can be issued by the client, or it can be started by the transaction manager when the transaction times out.
Timing out the transaction and performing the rollback at the transaction manager is important because it unlocks the objects in the grid.
There is no persistence or transaction log action for a rolled-back transaction.
The manager simply has to inform all the transactional entries in the grid that it is necessary to rollback and then mark the transaction control information as rolled back.