Transactional Caches and Write Through

Question

I've been trying to implement the use of multiple caches, each with write through, all within a transaction.
     The CacheFactory.commitTransactionCollection(..) method only seems to work correctly if the first transactionMap throws an exception in the database code.
     If the second transactionMap throws exceptions, the caches do not appear to rollback correctly.
     I can wrap the whole operation in a JDBC transaction that rolls back the database correctly but the caches are not all rolled back because they are committed one by one?
     For example, I write to two transaction maps, each one created from separate caches. When commiting the transaction maps, the second transaction map causes a database exception. It appears the first transaction map has already committed its objects and doesn't roll back.
     Is it possible to use Coherence with multiple transaction maps and get all the caches and databases rolled back?
     I've also been trying to look at using coherence-tx.rar as described in the forums within WebLogic but I'm getting @@@@@ Failed to commit: javax.transaction.SystemException: Could not contact coordinator at null+SMARTPC:7001+null+t3+
     (SMARTPC being my pc name)
     Has anybody else had this problem? Bonus points for describing how to fix it!
     Mike

Answer 1

The transaction support in Coherence is for Local     > Transactions. Basically, what this means is that the
     > first phase of the commit ("prepare") acquires locks
     > and ensures that there are no conflicts. The second
     > phase ("commit") does nothing but push data out to
     > the caches.
     This means that once prepare succeeds (all locks acquired), commit will try to copy local data into the base map. If there is a failure on any put, rollback will undo any changes made. All locks are cleared at the end.
     > The problem is that when you are using a
     > CacheStore module, the exception is occurring during
     > the second phase.
     If you start using a CacheStore module, then database update has to be part of the atomic procedure.
     >
     > For this reason, write-through and cache transactions
     > are not a supported combination.
     This is not true for a cache transaction that updaets a single cache entry, right?
     >
     > For single-cache-entry updates, CacheStore operations
     > are fully fault-tolerant in that the cache and
     > database are guaranteed to be consistent during any
     > server failure (including failures during partial
     > updates). While the mechanisms for fault-tolerance
     > vary, this is true for both write-through and
     > write-behind caches.
     For the write-thru case, I believe Database and cache are atomically updated.
     > Coherence does not support two-phase CacheStore
     > operations across multiple CacheStore instances. In
     > other words, if two cache entries are updated,
     > triggering calls to CacheStore modules sitting on
     > separate servers, it is possible for one database
     > update to succeed and for the other to fail.
     But once we have multiple CacheStore modules, then once one atomic write-thru put succeeds that means database is already updated for that specific put. There is no way to roll back the database update (although we can roll back the cache update). Therefore, you may end up in partial commits in such situations where multiple cache entries are updated across different CacheStore modules.
     If I use write-behind CacheStore modules, I can roll back entirely and avoid partial commits? Since writes are not immediately propagated to the database? So in essence, write-behind cache stores are no different than local transactions... Is my understanding correct?