[
https://issues.apache.org/jira/browse/JENA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965644#comment-14965644
]
ASF GitHub Bot commented on JENA-626:
-------------------------------------
Github user samaitra commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-149681690
@afs Thank you Andy. I really appreciate the review feedback and comments
and it will help me to iterate and move ahead with the changes . I will start
with implementation of **Capturing output** so that we can limit the changes to
Fuseki module.
**Caching and content negotiation**
Will make changes to adhere to requested format based on Accept header.
** Cache ResultSet **
The current implementation cache the resultSet java object for Describe and
Construct query but cache the resultset data by iterating over the result set
and capture output for Select and Ask queries. The challenge faced during
caching resultSet objects alone for Select and Ask queries was in case of
subsequent calls to iterate over results the resultSet object was closed and
returned error.
** Cache invalidation **
In case of Cache invalidation do we plan to invalidate all the Cache Entry
objects or only the impacted one. Invalidating all the Cache Entry objects will
be easier but may have performance impact based on frequency of write
operations but doing a selective CacheEntry invalidation is little tricky in
terms of selecting the key. The current Key is based on the SPARQL_Query but in
case of update the key has to be designed based on dataset and part of where
clause.
** Configuration and Control **
Yes, I am inclined for both the approach and approach 1 is much cleaner as
with new changes Fuseki module can return the captured output and not directly
write to ServletOutStream and flush results.
** Reuse the Guava already in Jena **
Yes, will do
** Extend to CONSTRUCT and DESCRIBE (future) **
The current implementation cache the resultSet for CONSTRUCT and DESCRIBE
queries but yes will extend to capture and cache results data for these queries
as well.
** Documentation and tests **
+1 will definitely add
> SPARQL Query Caching
> --------------------
>
> Key: JENA-626
> URL: https://issues.apache.org/jira/browse/JENA-626
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Assignee: Saikat Maitra
> 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)
