Hi Mark,
On 29/05/14 01:21, Mark Feblowitz wrote:
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()) {
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?
"No" to "Query" , "yes" to QueryExecution.
A Query is the parsed representation and can be used many times in many
places.
QueryExecution are one-time-use. (shh - it may not matter current in
some uses but that's what the overall contract is.)
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).
Each update for Fuseki+TDB is a transaction. There can be truly
concurrent readers; other writers are serialized by a lock.
If you ask the query before some write transaction completes, the
query/reader sees the old state of the database. Transaction are
isolation level "serialized" and there are no dirty reads etc.
In the case of a remote service query, the HTTP event happens in
execSelect. That defines the timepoint -- any manipulation of the
results is relative that that transaction point.
There is no point in looping on
try {
results = qexec.execSelect() ;
if (!results.hasNext()) {
once it's hasNext = false, it remains false. You need to redo the
QueryExecution step.
Andy
Thanks,
Mark
