ben-manes / caffeine / #5642

100%

master: 100%

push

github

Serialize the jcache remove/getAndRemove write-through under the bin lock

The JSR-107 CacheWriter contract requires the non-batch writer methods
to be "atomic with respect to the corresponding cache operation", but
CacheProxy.remove(K)/getAndRemove(K) called writer::delete before an
unconditional cache removal -- so a racing same-key put interleaved
between the store delete and the cache removal, leaving the store's
value while the cache went absent (a conformance violation; adversarial
F21, distinct from the putIfAbsent/invoke ordering fixed earlier).
removeNoCopyOrAwait now takes a publishToWriter flag and uses compute,
firing the writer under the per-key bin lock atomically with the removal
(mirroring putNoCopyOrAwait); it still fires unconditionally for an
absent key. This matches the RI and every peer (Ehcache3 uses the same
writer-inside-compute mechanism); only Coherence's in-process localcache
shares the old window.

removeAll stays on the batch deleteAll, which the spec explicitly does
not require to be atomic. Honoring deleteAll's residual collection on a
clean return (the RI's reading) would make removeAll a cache no-op for
any writer that does not clear the collection -- every mock and most
naive writers -- so remove-all-on-success is kept; the residual is
honored on the throw path. A per-key delete loop is permitted but
neither required nor more correct (Ehcache3 and Coherence-partitioned
also batch).

Pinned by a 2-thread interleaving test and a non-clearing-writer guard
in CacheWriterTest. Catalogued in jsr107-conformance.md, with the
write-through-under-compute convention in the adapter rule and the
asyncReload refreshes-bin-lock context added to synchronization.md.
Verified with :jcache:test and :jcache:tckTest.

4147 of 4158 branches covered (99.74%)

13 of 13 new or added lines in 1 file covered. (100.0%)

8416 of 8419 relevant lines covered (99.96%)

1.0 hits per line