Introduction

In this article, I’m going to explain how logical and physical clock versioning strategies work and why you should prefer using logical clocks for concurrency control.

Optimistic locking is a viable solution for preventing lost updates when running application-level transactions.

Optimistic locking requires a version column that can be represented as:

• a physical clock (a timestamp value taken from the system clock)
• a logical clock (an incrementing numeric value)

This article will demonstrate why logical clocks are better suited for optimistic locking mechanisms.

System time

The system time is provided by the internal clock of the current operating system. The programmable interval timer periodically sends an interrupt signal (with a frequency of 1.193182 MHz). The CPU receives the time interruption and increments a tick counter.

Both Unix and Windows record time as the number of ticks since a predefined absolute time reference (an epoch). The operating system clock resolution varies from 1ms (Android) to 100ns (Windows) and to 1ns (Unix).

Monotonic time

To order events, the version must advance monotonically. While incrementing a local counter is a monotonic function, system time might not always return monotonic timestamps.

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 solution or Bitronix Transaction Manager Monotonic Clock.

2. System#nanoTime(), that returns the number of nanoseconds elapsed since an arbitrarily chosen time reference

System time is not always monotonically incremented.

Database timestamp precision

The SQL-92 standard defines the TIMESTAMP data type as YYYY-MM-DD hh:mm:ss. The fraction part is optional, and each database implements a specific timestamp data type:

When it comes to persisting timestamps, most database servers offer at least 6 fractional digits. MySQL users have long been waiting for a more precise temporal type and the 5.6.4 version had finally added microsecond precision.

On a pre-5.6.4 MySQL database server, updates might be lost during the lifespan of any given second. That’s because all transactions updating the same database row will see the same version timestamp (which points to the beginning of the currently running second).

Prior to the 5.6.4 version, MySQL only supported second precision timestamps.

Handling time is not that easy

Incrementing a local version number is always safer because this operation doesn’t depend on any external factors. If the database row already contains a higher version number, your data has become stale. It’s as simple as that.

On the other hand, time is one of the most complicated dimensions to deal with. If you don’t believe me, check the for daylight saving time handling considerations.

It took 8 versions for Java to finally come up with a mature Date/Time API. Handling time across application layers (from JavaScript to Java middle-ware to database date/time types) makes matters worse.

Handling system time is a challenging job. You have to take care of leap seconds, daylight saving, time zones and various time standards.

Lessons from distributed computing

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

In distributed computing, logical clocks are favored over physical ones (system clocks) 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 one node (the database server) where all transactions are synchronized (coming from concurrent client connections).

Distributed computing favors logical clocks over physical ones because we are only interested in event ordering anyway.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

Using physical time might seem convenient at first, but it turns out to be a naive solution. In a distributed environment, perfect system time synchronization is most unlikely. All in all, you should always prefer logical clocks when implementing an optimistic locking mechanism.

Insert details about how the information is going to be processed

DOWNLOAD NOW