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.
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-Cach...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org