[
https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Castagna updated JENA-143:
--------------------------------
Description:
The interaction between queryExecution.abort() and TDB transactions seems to
suffer from a problem. 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)
This is the used coding pattern. 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();
was:
The interaction between queryExecution.abort() and TxTDB transactions seems to
suffer from a problem. 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)
This is the used coding pattern. 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();
> QueryExecution.abort seems to corrupt TDB when interrupting transactional
> queries
> ---------------------------------------------------------------------------------
>
> Key: JENA-143
> URL: https://issues.apache.org/jira/browse/JENA-143
> Project: Jena
> Issue Type: Bug
> Components: TDB
> Environment: tdb-0.9.0-20111010.121635
> Reporter: Simon Helsen
> Attachments: T_TransSystem_patchedForJena143.txt
>
>
> The interaction between queryExecution.abort() and TDB transactions seems to
> suffer from a problem. 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)
> This is the used coding pattern. 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();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
