[infinispan-dev] SKIP_CACHE_STORE usage

[Sanne Grinovero]

following up to my previous findings about SKIP_CACHE_STORE, I just
discovered that also using put()
I experience Store hits;
In InfinispanDirectory.java:230 I'm using: [*]

cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_STORE).put(
key, value )

as you can see from the following stacktrace, it's loading it from the store;
especially annoying as it shouldn't find anything there, as on this
type of key the SKIP_CACHE_STORE is consistently enabled:

at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.getLockFromKey(JdbcStringBasedCacheStore.java:158)
	at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:93)
	at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:133)
	at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:77)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132)
	at org.infinispan.interceptors.DistTxInterceptor.visitPutKeyValueCommand(DistTxInterceptor.java:76)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:76)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
	at org.infinispan.CacheDelegate.put(CacheDelegate.java:426)
	at org.infinispan.CacheSupport.put(CacheSupport.java:28)
	at org.infinispan.lucene.InfinispanDirectory.createRefCountForNewFile(InfinispanDirectory.java:230)
	at org.infinispan.lucene.InfinispanDirectory.createOutput(InfinispanDirectory.java:218)
	at org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:330)

This stacktrace was produced as I implemented a Key2StringMapper
intentionally not supporting a
specific kind of key, which should never be stored.

Shall we create a
SKIP_STORE_LOOKUP ?

Or better yet, I think that SKIP_STORE should work both for reading and writing:
Index: CacheLoaderInterceptor.java
===================================================================
--- CacheLoaderInterceptor.java	(revision 2171)
+++ CacheLoaderInterceptor.java	(working copy)
@@ -74,7 +75,7 @@
    @Override
    public Object visitPutKeyValueCommand(InvocationContext ctx,
PutKeyValueCommand command) throws Throwable {
       Object key;
-      if ((key = command.getKey()) != null) loadIfNeeded(ctx, key);
+      if ((key = command.getKey()) != null && !
ctx.hasFlag(Flag.SKIP_CACHE_STORE)) loadIfNeeded(ctx, key);
       return invokeNextInterceptor(ctx, command);
    }

this appears to pass all UT, but I don't know if this was actually
important for some form of locking.

Sanne

[*] it's not committed yet, I was experimenting with it to see
performance improvements or possible effects on ISPN-575