CacheLoader and cache beside pattern?

Question

We are using a cache beside pattern for writes (the cache is updated together with two databases (ther applications and a legacy database) using XA-transactions, For various reasons we cant use a write-through solution for updating the databases).
In order to avoid extra network trips and explicit locks etc I would however like to use a CacheStore for lazy loading objects to the cache (from the application database) - is this a recomended practise or can there be any problems with race conditions etc?
We will most likely use multiple service threads and my main worry is that one service thread may request an object from the cache store while the same object is updated using an XA-transaction (that consivably could be handled by another service thread) leading to a stale object geting loaded from the cache store and overwriting the newer value set by the transaction...
All sugestions are appreciated!
/Magnus

Answer 1

I am open to suggestions (with what options would it be doable?) but we usually go for optimistic/read committed.
If this would not work I see the alternative to be the following (on the application server where the near cache lives):
1. Try get X (may work from either front or back or fail and return null if not in either cache)
2. If it returns null, lock X
3. Ask database for X
4. put X
5. Unlock X
But this would quite bad, 4 remote accesses (plus the database access) per cache miss (since there is no unlockAll, putAndUnlock etc) compared to:
1. Try to read (if not in back cache CacheLoader will read it)
Just one remote access plus the database access...
Another problem with the first solution is that I will not be able to detect if the item does not exist even in database or if it is just not loaded - requests for non-existent items will always result in database access. With the second solution I believe the Coherent feature with caching "null" would reduce that problem significantly.
I was hoping that coherence was aware of what keys it is in the process of obtaining from a CacheLoader and refused to update them (i.e. locked them) until the cache loader completed but I cant find anything in the doc that would confirm that this is the case.
Would it be possible to write my own CacheStore where the "put" & "putAll" do NOT store anything to the database (I would still use XA-transactions to update the database!) and is only there to keep track of updates that has occurred while a database request is in progress or would there still be race conditions that could leave stale data in the cache? I was thinking that if the cache store detects that X has been updated while loading X from the database it could throw away the database result and instead return the new updated value that it could hold on to (in case it would get evicted again before the database request completed). An alternative would be that it vetoes the update transaction including X if it knows that X is in the process of being loaded from database - this would cause my application to wait a little while and then retry hopefully after the database load has completed...
It would actually be nice if a cache store could lock X while loading it. This would be the clean and very efficient since the lock operation would be local. Is this possible/allowed somehow? That could work "seamlessly" with the transaction handling (I believe - not being an expert on this subject!).
/Magnus
Edited by: MagnusE on Sep 3, 2009 7:45 AM