CacheLoader/Store invocation question

Question

I believe the documentation is not very detailed when it comes to exactly how cache loader / store is invoked. I would like to see documentation explaining for instance:
1. Does the default backing-maps or some other component in the infrastructure keep track of concurrent calls to the cache store / loader for the same key or is it the job of the cache loader / store to detect and optimize this if so desired (in order to avoid that the same missing object is loaded from database multiple times in cases where each node has several service threads and/or database connections)?
2. Does the default backing-maps or some other component in the infrastructure keep track of updates that occur while a cache loader / store is requesting an object in order to prevent possible race-conditions (for instance if multiple service threads and connections are used or if updates are done using "write beside" (directly done to both cache and database using XA) and read using "read through")?
3. Can a cache store find out if object are locked or not using some node-local API? Using the normal Coherence API would result in dead-lock I assume...
I would appreciate if somebody could give a little info about these things!
/Magnus

Answer 1

Hi Magnus,
MagnusE wrote:
To me it seems like a specially designed CacheLoader (that in order to collect the needed information also implements the CacheStore interface but don't perform any updates to the underlying database) COULD do the trick to let me combine "read through" (that lazilly load objects from a database) and "write beside" (using XA on the cache and the database).
The special CacheLoader would keep track of any pending load (or loadAll) requests as well as the keys involved. By implementing also the CacheStore interface it would receive information about any updates performed
and if they involve any keys in the process of getting retrieved from the database it would keep the new value until the database request has terminated and in this case replace the retrieved value with the updated one (since the value from the database MAY in this case be stale since it may be based on the data before the XA transaction got committed).
I do not exactly follow this. Could you write a full transaction lifecycle example?
I am, since this may have an impact on if this is 100% race-free, trying to find out the details about what value an Oracle database return when if one tries to query an updated value when "prepare" but not "commit" (in the XA-protocol) has been called. AFAIK, you get the old value with Oracle database if you read a row for which an update is pending but not committed (doesn't matter if it is prepared). If you want to update a row for which an update is pending, then the transaction of the update invoked later blocks.
Ideal in this case would be that it block such a requests until either commit or rollback has been called but I am not sure this is the case? AFAIK, it is not.
The race condition would as I see it occur only under a very unlikely case - namely if an updated value has been evicted and is geting loaded in again by the case loader during the period between prepare and commit/rollback...
Do you see any problems with the proposed solution? It seems attractive compared to the entry processor based proposal since it would work together with transactional map (that will call normal get/getAll in order to read data) and be much simpler for the programmer that (once the special CacheLoader is developed and in place) can follow the standard Coherence model for accessing data (get, getAll)...
Please, an example (even in mail... to my new email address, not the old EPAM one). :-)
Best regards,
Robert