Enlist Cache Store in a Cache Transaction?

[ma6rl]

I am using Infinispan 6.0.2 via the Wildfly 8.2 sub-system. I have configured a transactional cache that uses a String Based JDBC Cache Store to persist content placed in the infinispan cache. My concern is that after reading the following in the Infinispan documentation that there is potential for the cache and cache store to become out of sync when putting/updating/removing multiple entries into the cache in the same transaction due to the transaction committing/rolling-back in the cache but only partial succeeding/failing in the cache store.

4.5. Cache Loaders and transactional caches

When a cache is transactional and a cache loader is present, the cache loader won’t be enlisted in the transaction in which the cache is part. That means that it is possible to have inconsistencies at cache loader level: the transaction to succeed applying the in-memory state but (partially) fail applying the changes to the store. Manual recovery would not work with caches stores.

Could some one please clarify if the above statement only refers to loading from a cache store if it also refers to writing to a store as well.

If this is also the case when writing to a cache store are there any recommended strategies/solutions for ensuring a cache and cache store remain in sync?

The driving factors behind this for me is that I am using Infinispan both for write-through and over-flow of business critical data and need confidence that the cache store correctly represents the state of the data.

Many thanks in advance.

[ma6rl]

Linking to original discussion on the Modeshape forums Re: Can a Infinispan Cache Store get out of sync with the Cache when using Transactions?

[nadirx]

The short answer is: no.

We are thinking of allowing this for a very narrow case: with shared cachestores, where only the node which initiates the tx has the onus of writing all changes. However, because of the way the data is distributed in the cluster, the initiator node will need to retrieve all entries modified in the tx from the respective owners, and persist them.

[ma6rl]

Thanks nadirx for the information. This would be ideal given my uses case (n nodes either using replication or distribution backed by a shared JDBC cache store). If this was to go forward would it be targeted for the 7.x branch or 8.x? I currently use the Infinispan Sub-System in Wildfly via Modeshape which uses 6.0.2.Final and unfortunately neither of them will most likely move to newer version in the time frame I need but it would be good to understand when this feature may be implemented (if it is).

Another idea that I've had which may help improve fault-tolerance when writing to cache stores is to extend the AdvancedWriter SPI to support batching. If it was enabled all of the entries that need to be written in a transaction could be passed to the cache store in one call which would given the cache store implementation a chance to do a batch write. This has two benefits, one many persistence tiers have improved performance when doing batch writes, the second is the implementation could attempt to cleanup any partial writes on failure something which is not currently possible with the current SPI.

This would make integrating into NoSQL persistence stores which don't support XA such as MongoDB and DynamoDB more reliable.

[ma6rl]

nadirx is this ([ISPN-201] make JDBC cache store use DB transactions for commit/rollback - JBoss Issue Tracker) the issue being used to track the prosed changed?

Do you have any idea what release this change may be considered for?

The reason I'm asking is this is becoming a major issue for us. We use Modeshape as our persistence tier which in turn uses Infinispan to persist data via cache stores. Currently having the writes happen in the commit phase of a Tx mean that a) they do not get rolled back if a problem occurs b) the error does not get propagated to the application tier and we are unaware the Tx failed. This means that we are seeing problems both with the store and cache getting out of sync and with Tx completing successfully in the application tier but failing under the covers silently (other than logging an warning).