Querying objects not in the NamedCache

Question

The wiki topic on querying (http://wiki.tangosol.com/display/COH32UG/Querying+the+Cache ) points out that a query will "apply only to currently cached data".
     This seems fairly logical because it seems unreasonable to expect the cache to hold onto information that it has already evicted.
     If you were to design a DAO layer (following http://wiki.tangosol.com/display/COH32UG/Managing+an+Object+Model ) using the first of the following architectures:
     1. Direct Cache access:
     App <---> NamedCache <---> CacheStore <---> DB
     2. Direct Cache and DB-DAO access:
     App
     |
     CacheAwareDAO <---> CacheStore <---> DB
     |
     NamedCache
     |
     CacheStore
     |
     DB
     you would then have a situation where you would not be able to query evicted data.
     So by using the 2nd strategy I assume you would probably always want to bypass the cache for all queries other than by primary key, to ensure that you are always querying the entire persistent population.
     This seems a little coarse grained and also reduces the utility of the Coherence cache (unless the bulk of your queries are by primary key).
     Can anybody tell me if my assumption is wrong and if there are any usage strategies the mitigate this aspect?
     Thx,
     Ben

Answer 1

Hi Rob,     >
     > Why would you need 2 separate caches?
     the first cache would have eviction policy, and caches values, but does not have indexes
     the second would not have eviction, does not store data, but has index updates on changes.
     This way you have a fully indexed but not stored data-set, similarly to the difference between stored and indexed attributes Lucene.
     > Why not just
     > maintain a index within each cache so that every
     > entry causes the index to get updated inline (i.e.
     > synchronously within the call putting the data into
     > the cache)?
     >
     You cannot manually maintain an index, because that is not a configurable extension point (it is not documented how an index should be updated manually). You have to rely on Coherence to do it for you upon changes to entries in the owned partitions.
     And since Coherence code does remove index references to evicted or removed data, therefore the index would not know about the non-cached data.
     Or did I misunderstood on how you imagine the indexes to be maintained? Did you envision an index separate from what Coherence has?
     > (You may have to change Coherence to do this.....)
     Changing Coherence was exactly what I was trying to avoid. I tried to come up with things within the specified extension points, and the allowed things, although it might be possible that I still did not manage to remain within the allowed set of operations.
     Of course, if changing Coherence is allowed, allowing an option of filtering index changes to non-eviction events is probably the optimal solution.
     > And I don't think that the write-behind issue would
     > be a problem, as the current state cache of the cache
     > (and it's corresponding index) reflects the future
     > state of the backing store (which accordingly to
     > Coherence's resilience guarantee will definitely
     > occur).
     >
     The index on the second cache in the write-behind scenario would be out-of-synch only if the second cache is updated by invocations to the cache-store of the first cache. If it is updated upon changes to the backing map, then it won't. Obviously if you don't have 2 caches, but only one, it cannot be out-of-synch.
     > So you would have a situation where cache evictions
     > occur regularly but the index just overflows to disk
     > in such a fashion that relevant portions of it can be
     > recalled in an intelligent fashion, leveraging some
     > locality of reference for example.
     >
     I don't really see, how this could be done. AFAIK, all the indexes Coherence has are maintained in memory and does not overflow to disk, but I may be wrong on this, but again, I may have misunderstood what you refer on index handling.
     > a) you leverage locality of reference by using as
     > much keyed data access as possible
     > b) have Coherence do the through-reading
     > c) use database DAO for range querying
     > d) if you were to use Hibernate for (c), you might be
     > able to double dip by using Coherence as an L2 cache.
     > (I don't know if this unecessarily duplicates cached
     > data....)
     >
     > Any thoughts on this?
     a: if you know ids on your own, then this is the optimal solution, provided cache hit rates can be driven high enough. if you have to query for ids, the latency might be too high.
     b: read-through can become suboptimal, since AFAIK, currently the cache store reads all rows one by one, only read-ahead uses loadAll, but I may be wrong on this. Loading from database can be optimized for multiple id loading as well, to be faster than the same via cache store. So it is very important that the cache hit rate be very high for performance-relevant data in case of read-through.
     c: use database dao for complex querying, possibly almost anything more complex than straight top-down queries. make performance tests for both solutions, try to rely on partition affinity, and try to come up with data structures that help with making indexes which can be queried with as few queries as possible, and with not too high index access count.
     d: you cannot query by Coherence on Hibernate second-level cache, as Hibernate second-level caches do not contain structured data, but contain byte[][]s or byte[], holding the column values serialized to it (separately or the same byte[], I don't remember which).
     Best regards,
     Robert