[infinispan-dev] support for XA CacheStores in 6.0

Dan Berindei dan.berindei at gmail.com
Wed Apr 11 08:59:04 EDT 2012


On Wed, Apr 11, 2012 at 1:32 PM, Manik Surtani <manik at jboss.org> wrote:
> You don't really explain how such inconsistencies are possible.
>
> I think it makes sense to go into this in more detail on the wiki.  For
> example, on prepare, the cache instance acquires in-memory locks and then
> writes to the cache store.  The cache store implementation keeps these
> modifications in memory.  Later, on commit, the cache instance writes to the
> in-memory container, flushes the cache store, and then releases locks.
>

Writing to the cache store during prepare only works if the cache is
the only/last participant in the XA transaction (assuming no OOM).
If the cache was not the last participant, another participant could
fail to prepare after we already wrote to the cache store, and it
would be impossible for us to roll back cleanly.

> But, TBH, even if for some reason the cache cannot write to the in-memory
> container at this point (e.g., an OOM exception) the transaction will have a
> heuristic outcome thanks to the exception response on commit.  The same will
> happen if the cache store cannot flush.  So IMO this is "just as consistent"
> as the in memory container anyway.
>
> On 10 Apr 2012, at 14:03, Mircea Markus wrote:
>
> Hi,
>
> This is the continuation of a conversation Tristan, Dan and myself started
> around adding support for XA cache stores in Infinispan 6.0. It is also
> related to the CacheStore API refactoring scheduled for 6.0 [1].
>
> The problem:
> When configuring an XA cache with a cache store it is possible for the cache
> store to end up out of sync with in-memory data. In order to overcome that
> we would need cache store enhancements.
>
> Whilst this is definitely a limitation and a nice to have feature not sure
> that 6.0 is the time and place to start this enhancement. Why?
> There doesn't seem to be any explicit demand from the community/JDG for this
> feature at the moment, so other features should take priority. There's also
> a potential workaround for this: don't configure a cache store but the user
> to manage the XA write in the store directly.
> Wdyt?
>
> I've also updated the documentation to clearly state that inconsistencies
> are possible[2].
>
> Cheers,
> Mircea
>
> [1] https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign
> [2] https://docs.jboss.org/author/display/ISPN/CacheLoaders#CacheLoaders-CacheLoadersandtransactionalcaches
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list