You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Paolo Castagna (Updated) (JIRA)" <ji...@apache.org> on 2011/11/17 10:56:52 UTC

[jira] [Updated] (JENA-143) QueryExecution.abort seems to corrupt TDB when interrupting transactional queries

     [ https://issues.apache.org/jira/browse/JENA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paolo Castagna updated JENA-143:
--------------------------------

    Summary: QueryExecution.abort seems to corrupt TDB when interrupting transactional queries  (was: QueryExecution.abort seems to corrupt TxTDB when interrupting transactional queries)
    
> 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 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