Suppose an application records a version marker on some data.
For example a database application might record UPDATE_TS as a datetime when a record was updated.
It could just be an integer version counter but the important point is it’s guaranteed to change for each version and (for all practical purposes) never repeat.

One common cause of ‘spurious’ revision is that the application ‘saves’ the record without (in fact) changing any values. So if we examine the record as read and then saved no (real) change has been made.

A further source of ‘spurious’ change behaviour is some downstream ‘reader’ process that is interested only in a strict subset of the data. The record holds data items D1,D2,D3 and D4 but the downstream reader is only concerned with D1, D2 and D4.

If the reader is monitoring the UPDATE_TS it will trigger if what (really) changed was only D3.

In many cases this doesn’t matter and there’s still often value in the UPDATE_TS and the burden is on the downstream process to examine the items D1, D2 and D4 in detail to determine is a relevant change has occurred.

Is there a name for this issue? The ABA problem is different. That’s when changes are missed by assuming two reads of A mean no change in between.

Is it the AAA problem? It’s a common phenomenon but I can’t find an accepted name for it.


Most likely this is undocumented behavior. Many systems automatically update date/time on update columns and many times this functionality is not well documented, although it is expected from a logical perspective.

As many have pointed out, most of the time there is not an issue with this. However, if there is a problem, then an investigation would need to take place to eliminate the spurious updates.

Additionally, there other ways to track changes than a simple update date/time. For example, one could compute a hash of the object being changed and compare that against the current object before updating. If they match, don’t update. This is more expensive and more complicated, so think about the consequences of implementing such as change versus a simple update.


Thanks to rwong for correctly identifying this as a Spurious Wakeup in a comment above.

In low-level programming a spurious wake up occurs when a waiting thread is ‘woken up’ from waiting on a condition variable but the condition the thread is waiting for is not met.

The phenomenon I’m looking at isn’t low-level but it is precisely analogous to Spurious Wakeup.

There are broadly two categories of spurious wakeups. In one (a) the thread is woken up but none of the data relevant to the condition has changed. In the other (b) the data has changed but the condition still isn’t met.

In a change log we might see (a) if the Producer is simplistic. For example, a User opens a dialog for edit. Makes no edits but clicks ‘OK’ to save the record. The application then ‘updates’ the underlying data without change and triggers a cascade of notifications even though nothing changed.

Type (b) might occur that the consumer is waiting for changes in a subset of some data that is monitored as a block by the producer. It’s often easier to have a broader definition of change than have the Consumer somehow inform the Producer precisely which changes are in its condition.

A number of comments point out that some level of spurious wakeup is usually tolerable. It’s also desirable to drive it down. Though in some cases the cure could be worse than the disease. For example too much burden could be put on the Producer to determine local condition variables of Consumers and the best design accepts that there will be Spurious Wakeups.

Augment your change notifications.

The record’s stamp timestamp field is making a promise:
Definitely nothing has changed since that timestamp.
Possibly zero things changed at that timestamp,
but definitely nothing since then.

You desire a stronger promise.
So over the whole record compute and store a hash field,
and refuse to update stamp if it hasn’t changed.
Equivalently, use a “{stamp}-{hash}” compound field.
But we can make stronger promises than that — fine grained promises.

the downstream reader is [not] concerned with [D3].

Ok, so create four stamp (or stamp+hash) fine grained timestamp fields.

Or create a confirmed_stamp field, which persists the timestamp
at which the consumer most recently announced it is caught up
with updates to this record.
(Maybe subtract some fixed delta for safety.)

Or create a recent history field which names
fields such as “D4” that were recently touched,
perhaps augmented by stamp and even by hash.
Eventually fields age out of the history,
perhaps via fixed K=3 reporting slots,
perhaps after fixed one-hour delay.
Or associate a distinct stamp with each and every field.

Or stop the madness, and do what the consumer really wants.
Use a pub-sub system such as Kafka.
Create a notification channel for each field.
If someone updates e.g. D2 and D3,
send a pair of notifications on the pair of relevant channels.
Make consumers responsible for delayed buffering / coalescing
of such notifications, to avoid repeated processing of same record.