[
https://issues.apache.org/jira/browse/JENA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289113#comment-14289113
]
Andy Seaborne commented on JENA-626:
------------------------------------
Sure - the cache layer as I envisage it is a (Fuseki) service over the query
endpoint coordinating across all data access and data update services. This is
not in-process caching.
I would not expect data services with the fine-grained security layer using
caching normally; this is for "public" data.
There is not the HTTP and above mechanisms to support per-user identification
to the level of reliability that the fine-grained security layer and I don't
think we should add them to Fuseki itself. Instead, they should work in
conjunction with the deployment environment (tomcat etc) where per user/group
or per regime caching would then be possible.
Fuseki's use of shiro is for service-level security.
> 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: gsoc, 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)
