[
https://issues.jboss.org/browse/ISPN-4559?page=com.atlassian.jira.plugin....
]
Dan Berindei edited comment on ISPN-4559 at 7/23/14 5:06 AM:
-------------------------------------------------------------
The logic in {{CacheLoaderInterceptor.loadIfNeeded()}} seems to be geared only for
commands in a tx context. In a non-tx context, we'd need something similar to
{{NonTxDistributionInterceptor.needValuesFromPreviousOwners()}}.
I think there's also a problem with the {{!ctx.isOriginLocal()}} check, which allows a
non-owner to read the entry directly from a shared store. The ISPN-2950 fix added a test
for this scenario ({{DistSyncStoreSharedTest.testGetOnlyQueriesCacheOnOwners}}), but I
don't think the test is correct. I think this only has performance implications,
though.
was (Author: dan.berindei):
The logic in {{ClusteredCacheLoaderInterceptor.loadIfNeeded()}} seems to be geared only
for commands in a tx context. In a non-tx context, we'd need something similar to
{{NonTxDistributionInterceptor.needValuesFromPreviousOwners()}}.
Replace fails with cache loader
-------------------------------
Key: ISPN-4559
URL:
https://issues.jboss.org/browse/ISPN-4559
Project: Infinispan
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Loaders and Stores
Affects Versions: 7.0.0.Alpha5
Reporter: Dennis Reed
Assignee: Dan Berindei
Fix For: 7.0.0.Beta1
cache.replace(key, oldValue, newValue) compares the current value in the cache to
oldValue, and if they differ it turns into a no-op.
However, CacheLoaderInterceptor does not load entries for a ReplaceCommand.
If the entry only exists in the loader and not in memory, this causes the replace to
fail.
CacheLoaderInterceptor must always load the value for a ReplaceCommand.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)