[ https://issues.apache.org/jira/browse/JENA-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254157#comment-15254157 ]
ASF GitHub Bot commented on JENA-626: ------------------------------------- Github user afs commented on the pull request: https://github.com/apache/jena/pull/95#issuecomment-213496231 **Intent and Abstraction** Fuseki-caching isn't going to beat Vanish so I think the better use of Fuseki-caching is supporting cases flexibility like (in the future) paging results. I've sketched something in a branch in a work area: https://github.com/afs/jena/tree/fuseki-cache This is a sketch and not for serious use - there is some quick-and-easy implementation, it's only lightly tested for one dataset only. No configurability. The classes changed are: `HttpAction`, `ResultsCache`, and `SPARQL_Query` to use the cache. `SPARQL_Query` has operations `processViaCache`, `prepareForCache`, `insertIntoCache`. It deals with two concurrent attempts to set the by letting them both run (it's the same answer right?!) and set the cache. The cache is invalided when `HttpAction.beginWrite` is called so all update routes are caught (SPARQL Update, GSP and the Uploader). I don't like that - it seems asymmetric that `beginWrite` is used and it assumes MR+SW. Cache actions are logged `** Cache`. **Space** If the query result (not the serialization) is stored, I would expect the memory footprint will be less because of sharing nodes with the original dataset. Any graph pattern matching variable ends up with the node-by-reference. Calculated expressions are fresh nodes. Long literals are shared. Literals from the data are not extra cost in memory. Let's assume that calculated nodes are small. This is usually true - but they may be a lot of them. The calculation of the memory cost, is now approximated by the total number of cells in the results, i.e approximate with "num of rows * num of columns" and it can be calculated while capturing the `ResutlSet` copy. We could put limits on the size of results sets cached and on total number of cells. Serialized results can easily sized. They do not share space though. **Configuration** We need some configuration control, both server-wide on the `fuseki:Server` object in config.ttl and on each service. Or use "Context" - caching is import so my suggestion is have properties to cl;early set values. The server-wide case is, I think, less important. I suggest putting the configuration on service, not the dataset, so you can have two different policies, like cached and not-cached, on the same data. The default should be "no caching". The having two services addresses the "cold cache/development" use case. We should still obey `Pragma: no-cache` and `Cache-control` but there are quite a lot of options and details so it might be wise to not aim to have everything for a first release, especially if caching is default off. #### Other Related-but-different observation: supporting conditional-GETs would be very good. Just keep an epoxy number/timestamp for each dataset. > 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)