On 11 Apr 2012, at 11:32, Manik Surtani wrote: > You don't really explain how such inconsistencies are possible.
we apply the changes to the store during the Commit phase of the 2pc. If this operation fails for whatever reason (e.g. DB is temporary down) then there's no way to recover from the transaction failure, i.e. replay the changes to the database at some further point in time. > > 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. will do. > 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. Not true. The recovery support we have implemented is there to solve just that and become consistent. There's no "just as consistent" but only "consistent" or "not consistent" :-) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
