[infinispan-issues] [JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

[Horia Chiorean (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037453#comment-13037453 ] 

Horia Chiorean commented on ISPN-4810:
--------------------------------------

[~dan.berindei]: unfortunately no, for a couple of reasons: 
1. https://issues.jboss.org/browse/ISPN-4983 - which seems to be only fixed in {{7.1.0}}. Without this we can't even compile our code against 7.x
2. we need to be able to support Wildfly. Atm. the latest final version of Wildfly is {{8.2.0}} which uses ISPN 6.x

So after this issue is fixed, it would help us if the fix was backported (at least to 6.x). If that's not possible, then we have to wait until there's a final version of Wildfly which uses a version newer or equal to {{7.1.0}}.

> Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-4810
>                 URL: https://issues.jboss.org/browse/ISPN-4810
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 6.0.2.Final
>         Environment: Windows 7 x64 (NTFS)
> Oracle JDK1.7.0_40
> Apache Maven 3.0.5
>            Reporter: Horia Chiorean
>            Assignee: William Burns
>              Labels: modeshape
>         Attachments: ispn_concurrent.zip
>
>
> Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario:
> * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction
> * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread
> ** checks that the string entries were added into the cache and
> ** checks that the entries were correctly appended to the List entry
> * the above steps are repeated a number of times
> On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario).
> If we either:
> * disable eviction or
> * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)