]
Will Burns updated ISPN-12097:
------------------------------
Summary: Invalidation Cache invalidation removes entry from store with new SPI changes
(was: NonBlockingStore.batch(...) unexpectedly triggers entry removal)
Invalidation Cache invalidation removes entry from store with new SPI
changes
-----------------------------------------------------------------------------
Key: ISPN-12097
URL:
https://issues.redhat.com/browse/ISPN-12097
Project: Infinispan
Issue Type: Bug
Components: Core, Loaders and Stores
Affects Versions: 11.0.1.Final
Reporter: Paul Ferraro
Assignee: Will Burns
Priority: Blocker
Attachments: Test.java
There seems to be something amiss with the new NonBlockingStore changes. When a
transactional invalidation cache is used with a shared cache store, I've observed the
entries published to the removePublisher of the NonBlockStore.batch(...) which should have
targeted the writePublisher. This seems to happen when a batch only contains writes, but
no removes.
See the attached test to reproduce the issue, which executes two simple cache operations
against a transactional vs non-transactional cache using a shared write-through store.
The transactional version fails due to unexpected removals triggered by the batch(...)
method (which, in the case of the JDBC store delegates to the deleteBatch(...) and
bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published
to the removePublisher of batch(...) when transactions are enabled causing entries to be
removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are
disabled, the batch(...) method is, of course, not in play, and everything works correctly
via the individual write/delete methods.