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
regions.
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
