It's more that this issue provided an excuse to revisit DOReaderCache, rather
than any actual issue in your refactoring.
Guava's CacheBuilder looks like a promising ready-made cache, backed by a
ConcurrentMap:
http://code.google.com/p/guava-libraries/wiki/CachesExplained
and is limited to just the one library (admittedly ~1.8MB), but no further
dependencies.
We could pretty much just have:
Cache<String, DOReader> cacheMap =
CacheBuilder.newBuilder().maximumSize(maxSize) .expireAfterAccess(maxSeconds,
TimeUnit.SECONDS).build();
On Aug 28, 2012, at 2:08 PM, frank <[email protected]> wrote:
> I don't really mind using a diff. impl for the underlying data structure
> currently it's using ConcurrentHashMap from java.util.concurrent which i have
> used for many cache implementations. the cache class itself i think was not
> reinventing the wheel. it's a standard lru implememtation for DoReaders.
> Ready made caches like ehcache on the other hand introduce an IMHO far too
> large overhead for such a simple cache.
> But using SoftReferences for the cache entries would probably make sense in
> situation with low memory...
> --
> *frank asseg*
> softwareentwicklung
> feichtmayrstr. 37
> 76646 bruchsal
> tel.: ++49-7251-322-6073
> fax.: ++49-7251-322-6078
> mail: [email protected]
> web: http://www.congrace.de/
>
> Edwin Shin <[email protected]> wrote:
> Looking at this again over my morning coffee, I think we ought to seriously
> consider re-implementing the caching using a synchronized LinkedHashMap or
> opt for Google's ConcurrentLinkedHashMap
> (http://code.google.com/p/concurrentlinkedhashmap/).
>
> I like the latter: well-documented, tested and now integrated in Guava.
>
> LRU caches are pretty well-tread territory and I'd rather not re-invent the
> wheel, other than as an instructional exercise.
>
> On Aug 28, 2012, at 1:42 AM, Edwin Shin <[email protected]> wrote:
>
> > Not sure if Chris is back from holiday.
> >
> > i did a really cursory review--sorry, I'm about to crash for the night.
> > Looks generally ok to me, but I didn't thoroughly review the expiry of
> > cache items, so someone with fresher eyes might want to have a look.
> >
> >
> > On Aug 27, 2012, at 2:33 PM, "Asseg, Frank" <[email protected]>
> > wrote:
> >
> >> Hola Guys,
> >>
> >> don't really know what to do about fcrepo-1058..
> >> @Chris did you a chance to review the fix? can i commit this into master?
> >>
> >> Have fun!
> >>
> >> Frank
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
