db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Cache Stuff
Date Wed, 27 Jul 2005 14:18:53 GMT
Hi Brian,

sorry for the late reply I had problems with my apache mail account and 
don't get any mails in the week of your post.

 > Brian McCallister wrote:
 > All (especially Armin):
 > Small request if you are rewriting the cache stuff: consider having
 > the PB explicitly call the cache (could be via listener always
 > registered to keep with current system) to tell it when it loads
 > something. Right now the cache implementation needs to register its
 > own listener with the PB, which makes it much more difficult for the
 > person writing the cache implementation. Let's try to make it easier
 > for them and promise that the cache will be notified of each object
 > load.
 > Thoughts?

I refactored the OJB 1.x again (in conjunction with the 1.0.x back port, 
it's really really hard work, hope I can check in the first part soon)

Now the caching stuff has three dedicated level:

- Materialization cache
Used for object graph materialization, materialized objects will be 
pushed to the session cache

- Session cache
Session cache of a PB instance. Cleared on PB.close. Similar to the per 
broker cache. But now each PB instance use this kind of cache. On commit 
the object of the session cache will be pushed to the application cache.

- Application cache
Represented by the ObjectCache interface. A global cache shared across 
the used PB instances.

The conjunction between the session cache (per broker) and the 
application cache (by default per PersistenceConfiguration or per class) 
is made by a interface called CachingStrategy. In the implementation 
classes you can specify how the objects from the session cache will be 
transferred to the application cache - e.g to enable a two-level cache 
only copies of the cached objects will be pushed to the application 
cache. The copying is done in the CachingStrategy, this will make 
ObjectCache implementations much easier (has never take care of tx 
boundaries) and each ObjectCache implementation can be used as "read 
cache" or "two level" cache dependent on the used CachingStrategy.

Additionally I think about creating ObjectCache instance based on 
cache-regions (by default the top-level class name will be used). Then 
each ObjectCache implementation can be used to represent dedicated cache 


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message