incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Helsen (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-143) QueryExecution.abort seems to corrupt TxTDB when interrupting transactional queries
Date Fri, 21 Oct 2011 13:38:32 GMT


Simon Helsen commented on JENA-143:

Andy, I don't have a test case right now. When I see a bug I report it. If it was easy for
me to produce a test case, I would do so. As far as I can see, there is no relation with JENA-131.

I think it is troublesome that you dismiss defect reporting if it does not contain a test
case. I am giving you as much information as possible to reproduce the problem. So far, the
bugs I have reported for TxTDB have always been "real" bugs, which eventually bite you. So
it is in everybody's interest to investigate them asap. I do what I can to help, but for us
Jena is a library deeply embedded in a framework and I am always very careful to see that
we are not violating any invariants. 

The reason I know that the QueryOperation.abort is negatively affecting what is going on is
because I can avoid corruptions as reported in this defect when I uncomment the line where
we call QueryExecution.abort. If I turn it on, the corruptions happen. 

The environment is very clear and I am asking in return if you have a junit which tests the
behavior of transactions while aborting queries? 

> QueryExecution.abort seems to corrupt TxTDB when interrupting transactional queries
> -----------------------------------------------------------------------------------
>                 Key: JENA-143
>                 URL:
>             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
> 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
                                   - Originating Exception:
> com.hp.hpl.jena.tdb.base.file.FileException:[12980][12980]: Impossibly
large object : 1936010863 bytes
> 	at
> 	at com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage$
> 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:!default.jspa
For more information on JIRA, see:


View raw message