Oracle 5.0 Reference Manual page 1594

When a transaction is committed, it is committed in main memory in all nodes on which the data
is mirrored. However, transaction log records are not flushed to disk as part of the commit. The
reasoning behind this behavior is that having the transaction safely committed on at least two
autonomous host machines should meet reasonable standards for durability.
It is also important to ensure that even the worst of cases—a complete crash of the cluster—is
handled properly. To guarantee that this happens, all transactions taking place within a given interval
are put into a global checkpoint, which can be thought of as a set of committed transactions that
has been flushed to disk. In other words, as part of the commit process, a transaction is placed in a
global checkpoint group. Later, this group's log records are flushed to disk, and then the entire group
of transactions is safely committed to disk on all computers in the cluster.
This parameter defines the interval between global checkpoints. The default is 2000 milliseconds.
•
TimeBetweenInactiveTransactionAbortCheck
Effective Version
MySQL 5.0.0
Restart Type: N
Timeout handling is performed by checking a timer on each transaction once for every interval
specified by this parameter. Thus, if this parameter is set to 1000 milliseconds, every transaction will
be checked for timing out once per second.
The default value is 1000 milliseconds (1 second).
•
TransactionInactiveTimeout
Effective Version
MySQL 5.0.0
Restart Type: N
This parameter states the maximum time that is permitted to lapse between operations in the same
transaction before the transaction is aborted.
The default for this parameter is
ensure that no transaction keeps locks for too long, this parameter should be set to a relatively small
value. The unit is milliseconds.
•
TransactionDeadlockDetectionTimeout
Effective Version
MySQL 5.0.0
Restart Type: N
When a node executes a query involving a transaction, the node waits for the other nodes in the
cluster to respond before continuing. A failure to respond can occur for any of the following reasons:
• The node is "dead"
• The operation has entered a lock queue
• The node requested to perform the action could be heavily overloaded.
MySQL Cluster Configuration Files
Type/Units
milliseconds
Type/Units
milliseconds
(also the maximum). For a real-time database that needs to
4G
Type/Units
milliseconds
1574
Default
1000
Default
4G
Default
1200
Range/Values
1000 - 4G
Range/Values
0 - 4G
Range/Values
50 - 4G