Transactions and JDBC Cache Loaders

[bwallis42]

I read the following in the Infinispan documentation yesterday

{quote}
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. 
{quote}

which is a worry.

I have a system that is using jbpm, jms, hibernate and jcr/modeshape. A typical scenario would be

• receive a JMS event from a topic
• Create a new subtree (for a document) in modeshape
• create and start a workflow instance in jbpm
• write a new JMS event to a different topic.
• and maybe update some object state that is persisted via hibernate.

and then commit the results. Any failures in the logic of the above are expected to cause a rollback of all of the persistent changes so that the initial event could potentially be processed again or if not, the system is left in a consistent state wrt to the topics, document store and workflow instances.

without propagation of the transaction through to the jdbc connection used in the infinispan cache loader, the assumption of consistency is invalidated and I have a much more complicated scenario to implement.

There did seem to be some discussion about changing this behaviour in infinispan 6.x but no real plans or commitment that I could see.

Have I misunderstood this? It seems to me that it completely breaks the transactional model for modeshape *if* you want to persist your repository in a more traditional sense. My system will be a small number of nodes but will persist terabytes of data. Cache loaders are essential as there is no way we can keep it all in the cache.

[rhauch]

Yes, and I just confirmed with the Infinispan folks that the documentation is still correct. This is being addressed in Infinispan 6 with ISPN-604., since at the moment few of the underlying persistence systems for which there are cache stores have support transactions.

In the mean time, it does sound like the transaction would not be aware of any problems persisting the change in the cache store. IIUC, this wouldn't be an issue if Infinispan were configured as a data grid.

[jonathandfields]

Definitely a concern for my application as well, which much like Brian's, is a typical Java EE/JBoss app that is or will be using JMS, JPA, JBPM etc in a transaction and will want to enlist Modeshape as just another EE transactional resource into that same transaction. So to hear that Modeshape 3, which now supports JTA transactions, is not providing basic all-or-nothing transactional semantics at the persistence level is a concern. (I'm using BJBJE as the cache store.) I'll go ahead and vote for ISPN-604.