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.

  • what problem does the issue cause for you? mabey that has a name
    – Ewan
    Commented Oct 31, 2023 at 17:57
  • 1
    Why would an application save a record without changing any values? It seems like that would be a defect with the application.
    – Thomas Owens
    Commented Oct 31, 2023 at 17:58
  • 2
    In many cases this doesn't matter - I have a hard time to imagine cases where this matters. "No changes" is only a subcase of "few changes", but when a process can handle "few changes", there should be no special treatment necessary for "no changes". So why should this no-issue have a special name?
    – Doc Brown
    Commented Nov 1, 2023 at 3:15
  • @DocBrown In many cases it's not a problem and indeed often harder to drive out spurious change notifications than accept they happen. I once worked on a large system that spuriously versioned every record in a wide and large table every day and then notified another system of millions of spurious updates and that was a problem. The the 'record' is large and updates are frequent and false or irrelevant there can be an issue. I'm just looking for a name for a common phenomenon - the delta is 'fat' because it contains 'changes' where nothing changed.
    – Persixty
    Commented Nov 1, 2023 at 13:40
  • 1
    It is, in fact, called Spurious wakeup (wikipedia), as anyone of you might have guessed correctly. And it is also correct to say that the correct mitigation is for the listener to perform additional checks to suppress those spurious wakeup. When applied to networked database systems, it is beneficial for a type of "event listener" instances to be run as close to the DBMS as possible (same cluster, if not same machine) so that spurious wakeups do not need to be sent across the network.
    – rwong
    Commented Nov 3, 2023 at 1:56

3 Answers 3


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.

  • In my experience it's often known behaviour and as everyone points out in many cases not an issue. But it's common suboptimality of processes that are by their very nature intended to avoid excessive processing by only reacting to change. But it appears there isn't a name for the thing we're trying to drive out. Hashes are at best neutral because it is in practice usually impossible to pick out 'what' changed from among the contributions to a hash by the inspection of the hash alone.
    – Persixty
    Commented Nov 3, 2023 at 8:11

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.