You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org> on 2011/10/21 11:34:32 UTC
[jira] [Commented] (JENA-143) QueryExecution.abort seems to corrupt
TxTDB when interrupting transactional queries
[ https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132551#comment-13132551 ]
Andy Seaborne commented on JENA-143:
------------------------------------
(from JENA-131Transaction)
Please can we have a test case, not a fragment? From JENA-131, you've talked about heavy read/write concurrent access. If this the same? Is it always or sometimes?
It's really hard to track this down when the environment is unclear.
Abort should only set flags, and the clearup is done on the query thread itself.
> QueryExecution.abort seems to corrupt TxTDB 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
>
> 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();
--
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