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.
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.
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).