Model cache with time-to-live

[Martynas Jusevicius <ma...@graphity.org>]

Hey all,

I've been using FileManager to load and cache Models. However when it
comes to real-world caching using HTTP headers, its approach is too
simplistic since it does not take into account timestamps and
time-to-live.

I wonder what's the simplest way to amend that? Has anyone implemented
such functionality?

I already have a FileManager subclass that overrides several of its
methods, so I could probably implement the time-to-live logic by
overriding getFromCache() etc. But maybe it's easier just to wrap some
Memcache client in those methods and let it do the work.

Martynas
graphity.org

Re: Model cache with time-to-live

[Andy Seaborne <an...@apache.org>]

On 20/04/12 12:42, Martynas Jusevicius wrote:
> Hey all,
>
> I've been using FileManager to load and cache Models. However when it
> comes to real-world caching using HTTP headers, its approach is too
> simplistic since it does not take into account timestamps and
> time-to-live.
>
> I wonder what's the simplest way to amend that? Has anyone implemented
> such functionality?
>
> I already have a FileManager subclass that overrides several of its
> methods, so I could probably implement the time-to-live logic by
> overriding getFromCache() etc. But maybe it's easier just to wrap some
> Memcache client in those methods and let it do the work.
>
> Martynas
> graphity.org

Hi there,

I completely agree the caching in FileManger is inadequate.  In 
reworking this area [1], I have currently dropped the cache.  I'm not 
sure it provide much benefit and, because it's HTTP-independent, it's 
not sensitive the HTTP-level control.

It looks to me as if caching needs to be protocol specific.  Caching in
LocatorURL is needed so that it is sensitive to HTTP cache control. 
LocatorFile might also benefit from a cache which seems if the files 
mtime has changed.

Actually, for HTTP, this could be done by running a same-machine caching 
web proxy (e.g. squid) and then you get to use all the HTTP knowledge of 
cache management.  For all it's nice abstraction for REST, HTTP as a 
protocol is amazingly complicated and mixes all sorts of different 
concerns into one big mass.  The memcache client is much the same idea.

If these caches existed, other caching looks to me to be less useful. 
But if it still is useful, a Locator looks like a good place to put it, 
not in the FileManager itself.  You can achived different caching 
effects (e.g. memory vs disk, different policies like LRU or always (or 
precache) cache certain URLs) by choosing different FileManager setups. 
  At the moment, it's fixed and that feels bad.

So the short answer is in LocatorURL or create LocatorCacheHTTP to wrap 
a URL Locator.

	Andy

[1] 
https://svn.apache.org/repos/asf/incubator/jena/Scratch/AFS/Dev/trunk/src/main/java/projects/riot_reader/