Suggested feature useful for side cache scenarios

Question

According to a phone discussion with Jon Purdy, when using a TransactionMap/CacheAdapter, a large amount of lock-related traffic goes out to the cache servers, even in case of OPTIMISTIC/GET_COMMITTED (in the Coherence prepare phase of the JTA transaction commit, in this particular setting) .
     Let's consider the situation, when the same data is written to the database (Oracle) and to the transactional-cache together, first writing the row to the DB, then to the cache. Let the transactional cache be configured as OPTIMISTIC/GET_COMMITTED, and the DB configured as READ_COMMITTED.
     In this case, the DB ensures, that after prepare() on the XAResource for the Oracle connection completed, you acquired the corresponding lock in the DB to all entries that Coherence would try to lock. These locks in the DB would be released during DB commit.
     Therefore, in this situation, all Coherence locking and lock releasing operations (which would come after DB prepare and before DB commit, so i.e. they would be held only while all the corresponding locks also exist in the DB) are unnecessary, provided all the clients use this policy to write to the DB and the cache.
     Therefore I would suggest a property for the CacheAdapter which would disable lock-related traffic in situations like this. It could also be extended to the TransactionMap, because similar mechanisms might be in place with other resources as well, not only 2PC Oracle.
     This could reduce the latency of the Coherence commit operations in these cases.
     Of course, I may have overlooked something, but currently I believe what I wrote up there is correct.
     Best regards,
     Robert

Answer 1

Hi Robert,
     Considering the situation where Coherence:
     * is acting as a "fully reliable" cache (e.g. using a cache entry in an optimistic transaction will never result in a rollback)
     * only caches data from other data sources (e.g. Coherence never acts as the system of record)
     There are two primary means of affecting the state of the cache:
     * updates to the database will update the cache
     * reads from the database will update the cache
     The challenge is how to handle the situation where one thread is committing changes and another thread is reading from the database. Oracle usually will not block reads (especially with READ_COMMITTED), so these are fully concurrent operations.
     So you could end up with the sequence (simulating the existance of global time, and ignoring potential server failures):
     t1 SELECT from Oracle (A=1)
     t1 UPDATE to Oracle (A=2)
     t1 PREPARE (acquires lock)
     t2 reads from cache (A=1)
     t1 COMMIT and update the cache (A=2)
     This would show up as a optimistic concurrency exception (if t2 tries to commit). The only difference is that t2 got "stale" (obsolete READ_COMMITTED) data from the cache rather than the database. Cache reads will generally be no more dirty than database reads.
     In this particular case, you can clean up cache reads by pinning active items out of the cache. In other words, lock the cache entry and then mark the entry as "temporarily nonexistant". Subsequent reads will block (if reading with a lock) or will read dirty data (if reading without a lock) ... it's the usual tradeoff between optimistic and pessimistic concurrency strategies. For read-heavy apps that can tolerate the occasional rollback, you can get by with dirty reads. For write-heavy apps, or those that can't handle rollbacks cleanly, you'll want to use the cache locking approach (effectively using the cache as a pessimistic "throttle" for the optimistic database).
     Using this pinning approach converts the transactions to hierchical form, allowing you to explicitly lock cache entries, with better reliability characteristics than XA transactions, and with less overhead.
     The short form of this is that you might not want to use Coherence as a transactional resource if it is acting as a pure cache of the database. If you have data in Coherence that is not in the database, then the current transactional approach is probably best.
     Thoughts/comments?
     Jon Purdy
     Tangosol, Inc.