I’m encountering a situation in which the assertions (updates) are being posted
into TDB via Fuseki at a fairly high rate and queries are also happening pretty
quickly. There are times where a query returns an empty result when a known
result will eventually land in the triplestore.
The current situation is pretty bad - I’m seeing 280 queries and only 35
successful responses.
So, I have a couple of issues to resolve, but for the moment I’m trying to
focus on retries of a query. Is there a best practice for this? Examples?
The query is being executed via a standard QueryFactory
com.hp.hpl.jena.query.Query query = QueryFactory.create(queryString) ;
QueryExecution qexec = QueryExecutionFactory.sparqlService(service, query);
ResultSet results=null;
try {
results = qexec.execSelect() ;
…
Immediately following the query I test for results
try {
results = qexec.execSelect() ;
if (!results.hasNext()) {
and if none are found, I wait a bit and try again - in increasing intervals
until successful or until my time limit is exceeded.
The question is, must I create a new Query instance and/or a new QueryExecution
instance for each retry? And can I reuse the same result set variable for
subsequent attempts?
As for the larger problem, I’m wondering whether independently executed queries
(via possibly concurrent, separate invocations of a standalone jar) are handled
well by fuseki TDB. My loose understanding is the store is locked for each
update. Are the queries queued up, or are they executed with any concurrency?
Would there be a better way (other than via Fuseki) for such concurrent queries
(SDB is not an option).
Thanks,
Mark
