jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: [jira] Commented: (JCR-625) Memory is not freed up when jackrabbit-server war is redeployed in tomcat
Date Wed, 08 Nov 2006 10:53:54 GMT
On 11/8/06, Thomas Mueller <thomas.tom.mueller@gmail.com> 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
>

Mime
View raw message