[
https://issues.apache.org/jira/browse/JENA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963507#comment-14963507
]
ASF GitHub Bot commented on JENA-626:
-------------------------------------
Github user afs commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-149257400
`ETags` or `If-Modified-Since`+`Last-Modified` facilitate client-side
caching. The client already has a copy and wants to know if it is still
current and the server send either "your copy is good" or a new copy or whether
the server resource has changed. The client had to knowits the "same" query.
Having Fuseki support those would be good but not an alternative to a
server-side cache shared across clients. `ETags` also enable optimistic
concurrency control.
It would be possible to use have an intermediary (client to Fuseki, server
to the application) that managed a cache with Fuseki backend and, handling the
updates, could invalidate correctly. If those servlets (for each SPARQL
protocol and operation) were servlet filters, they could reside in a separate
machine/container/webserver or the Fuseki server itself. Code like this PR
could be the cache engine part of that.
> 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)
