Monotonically increasing time

http://vanillajava.blogspot.ro/2010/06/monotonically-increasing-time.html
http://grepcode.com/file_/repo1.maven.org/maven2/org.codehaus.btm/btm/2.1.4/bitronix/tm/utils/MonotonicClock.java
There are times you need to have a simple monotonicly increasing clock for timestamps but one which doesn't drift too far from the system time.

public enum Time {; 
    private static final AtomicLong lastTime = new AtomicLong(); 
    public static long increasingTimeMillis() { 
        long now = System.currentTimeMillis(); 
        long time = lastTime.getAndIncrement(); 
        if (now > time) { 
            lastTime.compareAndSet(time+1, now);
            return lastTime.getAndIncrement();  
        } 
        return time; 
    } 
} 

http://www.zynaptic.com/reaction/userguide/node14.html

https://dzone.com/articles/logical-vs-physical-clock

Java has two ways of fetching the current system time. You can either use:

1. System#currentTimeMillis(), that gives you the number of milliseconds elapsed since Unix epoch
   This method doesn’t give you monotonic time results because it returns the wall clock time which is prone to both forward and backward adjustments (if NTP is used for system time synchronization).
   For monotonic currentTimeMillis, you can check Peter Lawrey’s solutionor Bitronix Transaction Manager Monotonic Clock.
2. System#nanoTime(), that returns the number of nanoseconds elapsed since an arbitrarily chosen time reference
This method tries to use the current operating system monotonic clock implementation, but it falls back to wall clock time if no monotonic clock could be found.

Optimistic locking is all about event ordering, so naturally we’re only interested in the happened-before relationship.

In distributed computing, logical clocks are favored over physical ones (system clock), because networks time synchronization implies variable latencies.

Sequence number versioning is similar to Lamport timestamps algorithm, each event incrementing only one counter.

While Lamport timestamps was defined for multiple distributed nodes event synchronization, database optimistic locking is much simpler, because there is only on node (the database server) where all transactions are synchronized (coming from concurrent client connections).

Argument 4: Distributed computing favors logical clock over physical ones, because we are only interested in event ordering anyway.