directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <>
Subject Re: MRU in JDBM
Date Mon, 24 May 2010 12:09:52 GMT
On Mon, May 24, 2010 at 5:17 PM, Emmanuel Lecharny <> wrote:
> Hi guys,
> going deeper into the JDBM code, I'm currently reviewing the MRU class used
> into the CacheRecordManager. It has a few flaw I think we should correct
> (not that the code is wrong, but it can be sanitized. Here are the suggested
> fixes :
> - it internally uses a Hashtable, a data structure considered as legacy. One
> first option would be to use a Map instead (not synchronized, less potential
> contention)
> - it has a elements() method which returns an Enumeration on top of all the
> elements in the cache, used by the CacheRecordManager to determinate which
> element is dirty.
> - it's not synchronized (however, the underlying storage is)
> Otherwise, it's strictly a MRU where each updated element is moved to the
> top of the list, the oldest one being evicted. Some listeners can be called
> in this case.
> Here, we may want to either use an external library (ehcache which is using
> an ASL 2.0 license?) Any other idea ?

Seems like ehcache is a nice fit. it has most of the things needed,
and is ASL 2.0

I am really not very sure about the inner working of JDBM, but there
is one feature of ehcache that can
be particularly useful. Its multiple cache decorator's. You can have
once decorator which can provide read-only view
hence no locking overhead. On the same cache, you can have another
decorator which can be used for read-write ops, which incur
locking overhead.

Ehcache 2.1.0 release has all these new features

Ehcache is something i work on most of the time at my work (not
working on code), but building diff solutions.

We can do a quick PoC to see the numbers, and also we can tweak it for
performance :)


View raw message