Chapter 10. Transaction Logging
CloudTran has a built-in transaction logging facility, which
make a durable record of a committed transaction before returning to the committing client.
Transaction logging is important during a complete grid outage, where all data is lost.
You can override the built-in transaction logger by listening to Manager events and handling log requests.
doLog() method for more information on using your own logging implementation.
If you do not implement your own logger, the CloudTran logger will be used.
The CloudTran logger keeps a copy of the transactions that will be sent to a persistent store.
If you are using CloudTran for TopLink Grid described here, this will be all non-empty transactions.
If you are using the Low-Level API, a transaction will be logged if the
Transformer creates some persistable objects.
Although all nodes in a CloudTran system - the nodes holding the in-memory data
and the transaction buffer - should be run with one or more hot failover nodes,
a complete failure will cause transactions to be lost from in-memory before they have been persisted to the persistent store.
In theory, this is unlikely; in decision-makers' thinking, it looms large.
In this case, CloudTran ensures you can 'replay' the transaction log so that transactions that were committed
during normal running are sent to the persistent store.
This is very important because it means applications can carry on while information is being sent to the database - which is much slower than committing to memory.
It also means that CloudTran doesn't have to keep to the transaction boundaries marked by the application.
On persisting, CloudTran reorders transactions and sends them to the database in batches.
In doing so, it makes sure that any rows that are affected by two different transactions are isolated on the way to the database.
10.3 Log File Replay