Inserts trigger superfluous invalidate messages

Description

During debugging op HHH-12036, I noticed that every insert of an entity on node1 triggers a superfluous InvalidateCommand for that entity to all other nodes in the cluster. As this is a newly inserted entity, I see no reason for this invalidation. The entity cannot exist in the cache on another node.

Perhaps the fix is as simple as using Flag.CACHE_MODE_LOCAL at https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/access/NonTxInvalidationCacheAccessDelegate.java#L38

Activity

Show:

Emond Papegaaij July 12, 2018 at 1:13 PM

At the time we were doing some profiling, benchmarking and troubleshooting of our WildFly based Infinispan cluster. I noticed this issue thought it might be of interest to you. In our application insert volumes are not that high, so it's only of minor concern to us, but I suspect others could be suffering more (for example with append only tables). Back then this was the place to report these issues. We are still interested in a fix (we are still using WildFly with Infinispan in a cluster), but this is only a minor issue to us.

Radim Vansa July 12, 2018 at 12:53 PM

Let's keep it there, no need to duplicate... I took the chance to inform users here (and did not notice this is an old one).

Guillaume Smet July 12, 2018 at 12:45 PM

maybe it's worth migrating the issue to the ISPN issue tracker ourselves?

It's an old one so I'm not sure Emond is still interested in it but if it's still in the wild, we might want to fix it anyway.

Radim Vansa July 12, 2018 at 12:35 PM

Please note that bugs in Infinispan 2LC should be reported in Infinispan JIRA - https://issues.jboss.org/projects/ISPN as we do maintenance there.

Looks valid to me as well, though I agree that I don't see much reason to doing local invalidation when we wouldn't broadcast one. We need to keep the local invalidation record in pending-puts cache, to prevent this situation:

TX1: DB insert (v1), release DB locks
TX2: DB read (v1), cache putIfAbsent (v1)
TX2: cache invalidate & lock, DB modify (v2) & commit
TX2: cache putIfAbsent (v2)
– v2 gets evicted somehow –
TX1: cache putIfAbsent (v1) -> result is a stale entry

Guillaume Smet July 12, 2018 at 11:00 AM

Hmm, the OP is complaining about Infinispan sending invalidation commands to the entire cluster if we insert an entity.

Looks like a valid issue to me if he's right.

Details

Assignee

Reporter

Components

Priority

Created October 18, 2017 at 12:58 PM
Updated September 28, 2023 at 11:54 AM