[infinispan-issues] [JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-8008:
------------------------------------

Option 2 might work if the cache is not bounded, but when it is bounded it doesn't make sense to keep a potentially unlimited number of entries with errors in memory. Also, it sounds very similar to option 1 with a huge {{modificationQueueSize}}.

> Add Fault-tolerance to write-behind stores
> ------------------------------------------
>
>                 Key: ISPN-8008
>                 URL: https://issues.jboss.org/browse/ISPN-8008
>             Project: Infinispan
>          Issue Type: Enhancement
>          Components: Loaders and Stores
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>
> Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. 
> We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. 
> To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options:
> * Attempt a write and catch an exception if the store is not currently available
> * Add a method to return the current status of a store to the CacheWriter interface



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)