Re: Comment on ContainerCache?

[prev] [thread] [next] [Date index for 2004/07/16]

I've plans to generalise the caching mechanism. It should be easy for
a class to specify or implement a wide range of caching behaviours
(not just high/low-watermark but also max-age and others).
The internals need to change a little to make it easy to do such
things as plugins.

Tim.

On Fri, Jul 16, 2004 at 08:27:58AM +0200, Heiko Klein wrote:
> After reading about the LiveObjects in CDBI and idea sprang into my mind 
> (well, more an adaption from EJB container) and before I start 
> implementing it, I would here comments about it. So idea is as follows:
> 
> Similar to LiveObjects, I would apply a ContainerCache per class/table. 
> When retrieving a object/row, it would first look in the CacheContainer 
> and only when it doesn't exists there, it would connect to the database 
> and put it into the ContainerCache.
> 
> The difference to LiveObjects is the lifetime of objects in the 
> ContainerCache, which would be much longer than in LiveObjects, i.e.
> a) as long as the low-watermark hasn't been reached, objects will live 
> forever
> b) above the high-watermark, all objects with refcount < 1 (not 
> currently referenced in the rest of the program) will be removed until 
> the low-watermark is reached
> 
> 
> The main disadvantage I currently see:
> The cycling through the ContainerCache and testing for refcount < 1 
> might take some time.
> The program will need more memory (depending on the high-watermark)
> 
> The main advantage:
> * Much less round-trips to the database
> * 'LiveObject' like features without dependence on 
> garbage-collector/weak-references (identical to LiveObject when 
> high-watermark = 0)
> * General and centralized caching system (Currently, I'm usually caching 
> small (<100 rows) table completely, and for large tables I make sure 
> that I keep my rows long enough alive so that I skip roundtrips.)
> 
> 
> Comments are very welcome, in particular since it will be very hard to 
> implement it as Plugin.
> 
> Best regards,
> 
> Heiko