On 03/02/17 21:41, George News wrote:
Hi all,
On my environment I have created a class in order to encapsulate access
to `Dataset` and `Model`s stored. I didn't realize that the
`QueryExecution` instance was not collected by the GC
Just because
It should GC'ed. This depends on the storage but all the memory ones
and TDB that come with Jena itself don't rely on ".close()". It is as
much a case of recognizing that QueryExecution is use-once.
and it seems that
could lead to memory leak. In this sense I found that
`ResultSetFactory.copyResults()` detach the `ResultSet` from the
QueryExecution.
ResultSetFactory.copyResults() is materializing the results and creating
a List<> to keep them in so it isn't a huge copy.
If the app is going to iterate over all the results, this is more a case
of moving where work is done, not increasing or decreasing the work.
My concern now now is about performance: ¿Is it really consuming to
perform a copy of thousands of data? Would it be better to create
another class acting as a wrapper for the Jena `QueryExecution` and just
only read the `ResultSet` once.
This is the kind of thing I'm referring to.
```java
// query is a Query
// ts is the class encapsulating the management of the triple store
SparqlExecutor exec = new SparqlExecutor(query, ts);
ResultSet res = exec.execute();
// Do what ever with the resultset
exec.close()
```
Within the `execute` function I manage the transaction, get the
corresponding named graphs, etc.
JENA-1215 : ResultSetCloseable -- this will be in Jena 3.2.0.
This may help if you want to pass the ResultSet around - it keeps the
QueryExecution around to close it.
Andy
Thanks a lot.
Jorge
P.S.: It is difficult to explain things without disclosing the code :(
sorry.
