[infinispan-dev] REPL async semantics in the context of Hibernate 2LC

[Galder Zamarreño]

Hi all,

Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain:

I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode.

One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async.

If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B.

However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay...

The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine.

However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1]

So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off?

Cheers,

[1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
--
Galder Zamarreño
Infinispan, Red Hat