CODEWITHSUNDEEP
cachingtransactionsinfinispan
lucasweb
lucasweb

Reputation: 1786

Enlisting a Infinispan Cache Store in a Cache Transaction?

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.

I have also asked this question on the Infinispan Forums

Many thanks in advance.

Upvotes: 2

Views: 417

Answers (1)

Radim Vansa
Radim Vansa

Reputation: 5888

It applies to writes as well, failure to write to the store does not affect rest of the transaction.

The reason for this is that the actual persistence API is not transactional (edit: newer versions of Infinispan support transactional persistence, too). Therefore, with 2-phase commits (in first phase - prepare - all locks are acquired, in second one - commit - the write is executed) the write to the store is executed in the second phase. Therefore, the failure cannot rollback changes on different nodes.

Although Infinispan is trying to get close to strongly consistent in-memory database, it is still rather a cache given the guarantees. If you are more interested in the design limitations (and some of them also theoretical limitations), I recommend reading Infinispan wiki.

Upvotes: 3

Related Questions