Let me give me more detail how I set up the code. The main thread just
sets up the transaction, so, something like this:
DatasetGraphTxn dsGraph = null;
try {
dsGraph = StoreConnection.make(this.location
).begin(ReadWrite.READ);
Dataset ds = dsGraph.toDataset();
...
QueryExecution qe = null;
...
try {
results = qe.execSelect();
...
} finally {
if (qe != null) {
qe.close();
}
}
} catch (QueryCancelledException e) {
if (dsGraph != null) {
dsGraph.abort();
}
} finally {
if (dsGraph != null) {
dsGraph.close();
}
}
A parallel thread may decide that the given query needs to be cancelled,
so it has access to the QueryExecution and may decide to call
this.queryExecution.abort();
The question is whether I am just coding this wrong or whether there is
possible flow which does not yet work in TxTDB
thanks
Simon
From:
Simon Helsen/Toronto/IBM
To:
[email protected]
Date:
10/19/2011 03:18 PM
Subject:
queryExecution.abort() and TxTDB transactions
Hi guys,
is the interaction between queryExecution.abort() and TxTDB transactions
tested? When I use it, it seems that the store corrupts again. Note that
when the QueryCancellationException is thrown, I actively abort the
DatasetGraphTxn object, but I am seeing
14:59:20,580 [477961341@qtp-1709008349-8] WARN
hpl.jena.sparql.engine.iterator.QueryIteratorCheck - Open iterator:
QueryIterFilterExpr/37159
and then shortly after:
15:00:34,691 [jazz.jfs.indexer.jfs_tests_default_consumer_name.triple]
ERROR com.ibm.team.jfs - Originating
Exception:
com.hp.hpl.jena.tdb.base.file.FileException:
ObjectFile.read(8072)[12980][12980]: Impossibly large object : 1936010863
bytes
at com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage.read(
ObjectFileStorage.java:294)
at
com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage$ObjectIterator.next(
ObjectFileStorage.java:409)
etc.
Note that I call queryExecution.abort() in a separate thread and I wonder
if it runs in trouble if the main thread (executing the query) is just
calling queryExecution.close()
Simon
