[
https://issues.apache.org/jira/browse/JENA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963207#comment-14963207
]
ASF GitHub Bot commented on JENA-626:
-------------------------------------
Github user osma commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-149196979
> Update operations must invalid the cache. A simple way is to simply
invalidate the whole cache. It is very hard to determine whether an update
affects a cache entry selectively.
This gives me an idea...
How about just adding support for a Last-Modified and/or ETag header to
Fuseki, based on the most recent update to the underlying data? Then any
compliant HTTP cache could be used in front of Fuseki. (There should also be a
Vary: Accept when that header was used to determine the result format.)
But if caching within Fuseki is truly needed, then I think Andy's detailed
review above charts the best ways of implementing it.
> SPARQL Query Caching
> --------------------
>
> Key: JENA-626
> URL: https://issues.apache.org/jira/browse/JENA-626
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Labels: java, linked_data, rdf, sparql
>
> Add a caching layer to Fuseki to cache the results of SPARQL Query requests.
> This cache should allow for in-memory and disk-based caching, configuration
> and cache management, and coordination with data modification.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
