On Apr 6, 12:06 am, Timothy Perrett <[email protected]> wrote:
> True, very true. I know DPP is generally against caching, but we all
> recognise the need to caching in a production environment. Perhaps, rather
> than asking if we should re-invent the wheel with a specific cache mech
> within lift, perhaps my quesiton is this:
>
> Is LRU and the KeyedCache abstraction sufficient for people to implement all
> our caching requirements within lift? You mentioned TemplateCache not being
> thread safe... Is there away we can provide some thread safe abstraction for
> users caching perhaps...
>
> Just rambling here :)
These are valid questions. LRU & KeyedCache utilizes
org.apache.commons.collections.map.LRUMap which is not thread safe. So
anyone can use them and handle concurrency separately by locks or
whatever
What I'd be keen to see is a (ConcurrentHashMap + SoftReferenceMap +
LRU)-ish concept. Perhaps using an actor would be nice as well ... I
still need to do some digging.
>
> Cheers, Tim
>
> > And to answer your previous question, about generic caching, I'd say
> > not necessarily. I'm working on templates caching but I'm not sure if
> > we should turn this into a generic caching mechanism. Maybe we can
> > talk more on your localization caching idea and see how it goes. I
> > wouldn't put a generic caching mechanism in lift .. but of course this
> > is not really my call. There are plenty generic caching mechanisms out
> > there and having lift to do that would probably be a too big
> > burden. ... it's just my personal view.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
