A long one...
The Idea:
--------
On the heels of the parameterized queries addition, I am planning to
implement caching of query results. This becomes possible now, since
parameterized queries can be shared, and therefore can be used as cache
lookup keys. Other parts of the cache key would be (2) a map of parameters
and (3) a list of ordering keys.
I need something like that for the customer project I am doing now (in the
past I did the cache outside of Cayenne, now I want this functionality to
be in the core framework). I would like to hear other's opinions on that.
Especially in the view of the recent discussion about the distributed
object cache.
Suggested feature is a bit different from just object cache (caching lists
instead of objects), and at the same time very similar (object snapshots
handling, cache refreshing and update notifications mechanism, etc.). So I
do not want it to drift too far apart from our main (still not completely
defined) caching handling strategy.
Design Notes:
------------
1. "Prototype" parameterized queries will be associated with Entities (I
guess both Db and Obj, since queries can potentially be done on both).
2. Eventually handling of query loading will be done in CayenneModeler
(just like EOModeler), for now this will be Java API that will need to be
called explicitly. I hope to use some of the new event functionality, but
it is quiet possible that I will simply stick the "prototype" query
building into static methods of corresponding DataObject subclasses.
3. DataContext will have a method calling a named query:
"objectsForQuery(Class, String name, Map params, List orderingKeys)
4. There will be a new class, ListCacheManager, using LRUMap from jakarta
commons-collections for the cache. ListCacheManager will be associated with
DataDomain and enable shared cache for all DataContexts.
5. Cache will store lists. Objects in a list will be generic
CayenneDataObjects containing ObjectId and snapshot, and not linked to any
DataContext. When retrieving objects to the DataContext, an new list of
objects is built, associated with this DataContext, based on the original
snapshots.
This does look a bit heavyweight, just like any other cache system. I hope
that a few things in this design should deliver performance improvements:
- (most obvious) fewer trips to the database
- fewer calls to "objectIdFromSnapshot"
Possible problems are:
- Caching IncrementalFaultLists (I am taking advantage of them now in many
places)
- Propagating snapshots between ObjectStore that belongs to DataContext and
ListCacheManager that is one level up, belonging to a DataDomain.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jan 20 2003 - 01:01:12 EST