[infinispan-issues] [JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-3665:
------------------------------------

The flush was needed with the bucket-based cache store because it opened the backing file every time it wanted to read or write an entry. The new single-file store uses the same file channel/descriptor for all the operations, so all the threads *should* see the same value. 

On the other hand, I think there may be a problem with the SingleFileStore locking... e.g. the free() method doesn't wait for concurrent readers to unlock the entry, so I think it could cause those readers to read an empty entry. And we probably need more logging in there as well...
                
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
>                 Key: ISPN-3665
>                 URL: https://issues.jboss.org/browse/ISPN-3665
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Loaders and Stores
>    Affects Versions: 6.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>              Labels: jdg620_dm, jdg62GAblocker
>         Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk.  This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null.  This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation).  It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira