On 11/8/06, Thomas Mueller <[EMAIL PROTECTED]> wrote:
Hi,
I agree, the CacheManager is an implementation detail and should not
exposed to other components as much as possible. I hope that the
CacheManager can be removed in the future, for me it is just a
workaround for the memory problem.
Unfortunately (and this is the root of the problem), there is not only
one single cache instance per repository / session, but one cache per
ItemStateManager. For me, the best design would be to have only one
cache, because only in this way the LRU algorithm (or whatever other
unfortunately that wouldn't work. as i've mentioned earlier the different
caches have specific semantics, e.g. some have to make sure that there
exists only 1 ItemState instance per id per session...
cheers
stefan
algorithm, maybe 2Q) can work like it should. One way would be to
extend the key of a cache item to include the ItemStateManager it
belongs to, but that would mean one more reference per cached object.
Currently, I would be afraid to change the cache architecture like
this, it would be not only much more work, but also more dangerous as
I don't know the Jackrabbit codebase good enough so far. Also, it
probably makes sense to wait until the SPI project is done.
I will change the implementation to reduce the visibility of the
CacheManager, so that it can be removed more easily later on.
Thomas
