[ 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)