6.3 Timestamps for MVCC
This section only applies to MVCC. There are no transaction timestamp generators for Pessimistic Locking transactions,
because timestamps are for information only, whereas in MVCC synchronized time is central to the design.
MVCC needs timestamps to retrieve the most appropriate value when multiple transactions overlap when changing a given cache entry.
This overlapping occurs from having one or both of:
These timestamps must be synchronized across all the manager nodes.
CloudTran provides two standard MVCC timestamp generators: the default (simple) generator, and a more scalable distributed timestamp generator.
These are both written in Java and operate within the transaction managers, using time from an isolator node.
You can also implement your own timestamp generator.
Your generator must implement the TimestampGenerator interface.
This may make sense if you have access to a standard timestamp generator in hardware or as a device driver (such as a PTP driver).
You plug in your custom class using the config property
The MVCC timestamp generator is configured at start of day and cannot be changed while the grid is running.
An MVCC timestamp can be retrieved by calling
- very hot entries, that are changing many times per second
- long running calculations, that use values that change relatively frequently.
CloudTran provides a default implementation for MVCC timestamp generation -
6.3.1 Default MVCC Timestamps|
This works by making calls to the isolator to get the start time and commit time for MVCC transactions.
While there are various optimizations that reduce the overhead of making these calls, you should plan for an overhead of two hops per MVCC transaction for timestamp generation.
In a very large grid with many managers, this approach will limit scalability.
For grids with fewer managers but a high transaction rate, the calls to the isolator will normally be aggregated with other requests
(to isolate transaction objects being sent to persistent stores like databases) so the overall scalability may be less of a concern than
the overhead at low transaction rates.
The DistributedMvccTimestampGenerator -
6.3.2 Distributed MVCC Timestamps|
runs at each manager, providing MVCC timestamps to the local JVM.
Very broadly, it works by
The details are more complicated than that: it is impossible to get the exact time at a remote node, and the overhead to retrieve the time
varies significantly on each call. This means that deducing the time at the isolator relative to a manager node requires tuning for the network environment as well as
statistical analysis of the history of the timestamps.
The issues with time coordination are
- requesting a timestamp from the primary isolator
- providing a 'getTimestamp()' service that adjusts the time returned to the manager based on the time elapsed since the last heartbeat - it doesn't just return the last isolator time.
- the clocks on machines cannot be simply set by hand - the required accuracy is much less than a network call
- CPU clocks run at different rates.
On similar machines, the accuracy can be as good as 1-2 parts per million (ppm);
on dissimilar machines, it can be as bad as 100-200 ppm.
- the roundtrip time to retrieve the time from the primary isolator can vary
- within the roundtrip time, the proportion for reading the time compared to returning the time can also vary significantly,
and this affects the manager's perception of time at the isolator.
How accurate does it need to be - we need a diagram.
184.108.40.206 Configuring Distributed Timestamps|
Copyright (c) 2008-2013 CloudTran Inc.