[
https://issues.apache.org/jira/browse/IGNITE-11371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796122#comment-16796122
]
Denis Mekhanikov commented on IGNITE-11371:
-------------------------------------------
[~agoncharuk] the changes look good to me. Consider adding tests for
transactional caches and having at least one backup.
Also I think, it would be good to have a test like follows, just to fix the
behaviour:
{code:java}
@Test
public void testRemoveIsApplied() throws Exception {
startGrid(0);
IgniteEx client = startGrid("client");
IgniteCache<Object, Object> cache = client.cache(TEST_CACHE);
String key = "key";
assertNotNull(cache.get(key));
IgniteFuture<Object> getFut = cache.getAsync(key);
cache.remove(key);
assertNotNull(getFut.get());
assertNull(cache.localPeek(key)); // Check, that remove actually takes
place.
assertNotNull(cache.get(key));
}
{code}
> Cache get operation with readThrough returns null if remove is performed
> concurrently
> -------------------------------------------------------------------------------------
>
> Key: IGNITE-11371
> URL: https://issues.apache.org/jira/browse/IGNITE-11371
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 1.8, 2.5, 2.7
> Reporter: Denis Mekhanikov
> Assignee: Alexey Goncharuk
> Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteInvalidationNullRunner.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider a situation, when you have a cache with {{CacheStore}} and
> {{readThrough}} configured.
> One may expect, that {{IgniteCache#get(...)}} operation will never return
> {{null}} for keys, that are present in the underlying {{CacheStore}}. But
> actually it's possible to get {{null}} in case if remove operation is called
> on the same key while {{CacheStore#load}} is running.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
