[infinispan-dev] SKIP_CACHE_STORE usage

Sanne Grinovero sanne.grinovero at gmail.com
Mon Aug 9 07:57:26 EDT 2010


2010/8/9 Manik Surtani <manik at jboss.org>:
> SKIP_STORE should bypass both get and put from the cache store.  This is a bug.  Your patch is valid, but you would also want to apply the same technique to visitRemoveCommand(), visitReplaceCommand(), visitGetCommand(), etc.
>
> Have you created a JIRA for this?

Thanks, now that I know that it's a bug I've opened ISPN-581.
I could try implementing this one myself, but will need directions on
how to apply this during batches or transactions: I couldn't retrieve
the context in the modifications, while each single modification might
have been invoked with different Flags. Adding the flag to the
modification container?

Cheers,
Sanne

>
> Cheers
> Manik
>
> On 6 Aug 2010, at 20:19, Sanne Grinovero wrote:
>
>> 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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list