CloudTran Home

 
  
<< Back Contents  >  10.  Transaction Logging Forward >>

10.1 Overview

 10.1.1  Use a Separate Disk
 10.1.2  Transaction Logging Operation Overview
 10.1.3  Configuring Logging

10.1.1  Use a Separate Disk
The most important point about working with transaction logging is, if you are using a disk drive, to use a separate drive that is dedicated to logging.

The first reason for this is that the logging algorithm is optimised to take advantage of the rotational delay on a magnetic disk drive. If the drive is shared with other applications, then the head movement reduces the performance of the logger, which increases latency.

The second reason is that using the operating system's home/boot disk seems to further reduce performance. For example, on a Linux test system, using a dedicated log disk gave log latency of 10-20ms; using the boot disk, the latency went up to 90ms or more.


10.1.2  Transaction Logging Operation Overview
The flow of events for the transaction logger depends on the setting of the ct.logger.logBeforeCommit and ct.logger.logAfterCommit configuration parameters. These are both boolean flags - true or false. One of these flags must be on for transactions to be logged (and if not, you can ignore this chapter).

If ct.logger.logBeforeCommit is true, which is the default, the actions are:

  1. The application requests the transaction buffer node (the TxB) to commit a transaction.
  2. The TxB writes the transaction data to the log with a 'persisting' marker.
  3. The TxB returns control to the application.
  4. The TxB persists the transaction to all data stores
  5. The TxB writes a 'persisted' marker for this transaction in the log, indicating that this log does not need to be replayed after a crash.
If ct.logger.logAfterCommit is true, steps 2 and 3 are reversed, i.e.:
  1. The TxB returns control to the application - before any write to a hard disk has been done.
  2. The TxB writes the transaction data to the log with a 'persisting' marker.
In the second sequence, by returning to the calling program immediately, the 'ct.logger.logAfterCommit' saves the latency of writing to the disk, which will typically add 10's of milliseconds (for example, c. 12 ms for a local hard disk). However, the transactions are at risk during this time: if the system crashes, then transactions that have been reported as committed may be lost. For many applications, this delay will be worth it to be sure that the transactions are secured to disk.

Our experience is that writing the transaction log will reduce CloudTran's maximum throughput capacity, but minimally, simply due to the extra length of queues and the increased control information that must be managed. The impact on response time, if any, of logging is more difficult to guage because it is normally done in parallel with committing into the grid; depending on the speed of the hardware, logging or committing may finish first.


10.1.3  Configuring Logging
You configure the logger in the same way as configuring other built-in properties. Logging property names begin with 'ct.logger'. The first one of them is described here.

The property you need to configure in most cloud deployments to get started is the logger directory.

Other properties you may want to configure for fine-tuning the logging system begin with "ct.logger".

Copyright (c) 2008-2013 CloudTran Inc.