[Lift] Re: TemplateCache
Yes by using read/write locks. Didn't use ConcurrentHashMap after all due to lack of LRU in it. Br's, marius On Apr 12, 9:07 pm, Timothy Perrett timo...@getintheloop.eu wrote: Interesting marius - I havent checked out the code yet, but did you manage to work around the thread safe issues? Cheers, Tim On Apr 11, 9:16 pm, marius d. marius.dan...@gmail.com wrote: I just committed a SoftReferenceCache implementation in utils and it is used by InMemoryCache. So far testing it looks pretty good. The point of a SoftReferenceMap is probably obvious to prevent (as much as possible) OOME. This is fine IMHO cause it's more important to have the application running an not crash due to large potentially large caches. Of course if a cache template is gc-ed it will be re-cached on the subsequent attempt to use it. I would appreciate any early feedback. Br's, Marius On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Just checked out the code Marius... this is good stuff! So one could use the SoftReferenceCache generically as a thread safe replacement for KeyedCache right? The template cache is pretty sweet also. Cheers, Tim On Apr 13, 7:20 am, marius d. marius.dan...@gmail.com wrote: Yes by using read/write locks. Didn't use ConcurrentHashMap after all due to lack of LRU in it. Br's, marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Interesting marius - I havent checked out the code yet, but did you manage to work around the thread safe issues? Cheers, Tim On Apr 11, 9:16 pm, marius d. marius.dan...@gmail.com wrote: I just committed a SoftReferenceCache implementation in utils and it is used by InMemoryCache. So far testing it looks pretty good. The point of a SoftReferenceMap is probably obvious to prevent (as much as possible) OOME. This is fine IMHO cause it's more important to have the application running an not crash due to large potentially large caches. Of course if a cache template is gc-ed it will be re-cached on the subsequent attempt to use it. I would appreciate any early feedback. Br's, Marius On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
I just committed a SoftReferenceCache implementation in utils and it is used by InMemoryCache. So far testing it looks pretty good. The point of a SoftReferenceMap is probably obvious to prevent (as much as possible) OOME. This is fine IMHO cause it's more important to have the application running an not crash due to large potentially large caches. Of course if a cache template is gc-ed it will be re-cached on the subsequent attempt to use it. I would appreciate any early feedback. Br's, Marius On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
I committed it of course in wip-marius-template-cache branch. On Apr 11, 11:16 pm, marius d. marius.dan...@gmail.com wrote: I just committed a SoftReferenceCache implementation in utils and it is used by InMemoryCache. So far testing it looks pretty good. The point of a SoftReferenceMap is probably obvious to prevent (as much as possible) OOME. This is fine IMHO cause it's more important to have the application running an not crash due to large potentially large caches. Of course if a cache template is gc-ed it will be re-cached on the subsequent attempt to use it. I would appreciate any early feedback. Br's, Marius On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
On Apr 5, 11:21 pm, Timothy Perrett timo...@getintheloop.eu wrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Totally agree. 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. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
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 :) 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
On Apr 6, 12:06 am, Timothy Perrett timo...@getintheloop.eu 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
Sounds pretty awesome to me Marius - looking forward to your thoughts Cheers, Tim On 05/04/2009 22:22, marius d. marius.dan...@gmail.com wrote: 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: TemplateCache
I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
