Package org.infinispan.interceptors.impl

Class ScatteredCacheWriterInterceptor

java.lang.Object
org.infinispan.interceptors.BaseAsyncInterceptor
org.infinispan.interceptors.DDAsyncInterceptor
org.infinispan.interceptors.impl.JmxStatsCommandInterceptor
org.infinispan.interceptors.impl.CacheWriterInterceptor
org.infinispan.interceptors.impl.ScatteredCacheWriterInterceptor
All Implemented Interfaces:
Visitor, AsyncInterceptor, JmxStatisticsExposer
public class ScatteredCacheWriterInterceptor extends CacheWriterInterceptor
Similar to DistCacheWriterInterceptor but as commands are not forwarded from primary owner so we just write to the store all the time (with non-shared interceptors). Uses its own locking scheme to order writes into the store - if there is a newer write into DC, the older write is ignored. This could improve contented case, but has one strange property: Assume CS contains V1, T2 writes V2 and T3 writes V3; if T2 receives version and stores into DC before T3 but arrives here after T3 the V2 write into CS is ignored but the operation is confirmed as if it was persisted correctly. If T3 then (spuriously) fails to write into the store, V1 stays in CS but the error is reported only to T3 - that means that T3 effectivelly rolled back V2 into V1 (and reported this as an error). This may surprise some users. Reads can be blocked by ongoing writes, though; when T2 finishes and then the application attempts to read the value, and removal from T3 is not complete yet the read would not find the value in DC (because it was removed by T3) but could load V1 from cache store. Therefore, read must wait until the current write (that could have interacted with previous write) finishes. TODO: block writes until other write completes, and don't block reads However, blocking reads in cachestore is not something unusual; the DC lock is acquired when writing the cache store during eviction/passivation, or during write skew checks in other modes as well.
Author:
Radim Vansa <rvansa@redhat.com>