On 19/03/13 16:55, Reto Bachmann-Gmür wrote:
On Tue, Mar 19, 2013 at 4:47 PM, Andy Seaborne <[email protected]> wrote:
On 19/03/13 15:35, Reto Bachmann-Gmür wrote:
On Tue, Mar 19, 2013 at 3:59 PM, Andy Seaborne <[email protected]> wrote:
On 19/03/13 13:57, Reto Bachmann-Gmür wrote:
So for the problem with the tdb tc provider I've made a first commit on
issue CLEREZZA-749.
It doesn't solve the problem only shows it more clearly.
Apparently jena tdb keeps the files open even after Graph.close has been
called making it impossible to delete them. I'm not sure how this could
be
solved or if we should raise an issue again Jena TDB.
(you are using an old version of TDB - even without transactions,
updating
will pick up various important bug fixes)
Ok.
A graph is just a stateless view on the database so closing a graph is a
bit of a no-op (it syncs the files if not transactional). Just
forgetting
about them is fine, no close required. Or do a removeAll() to clear
them.
The problem is that the underlying files are not closed and so they cannot
be deleted under windows. removeAll seems not to be available in the
version we are using.
Graph.remove(null, null, null) ;
Model.removeAll() ;
@Minto is the patch for CLEREZZA-726 ready to be applied or are you
working
on an update version?
TDB caches databases - it's expensive to keep opening and closing them
(no
disk caching benefits) and tracking whether its in use in Java isn't very
helpful. You can flush the cache but that will not avoid the windows
issue.
It could close the file when close on the graph is explicitely invoked?
One graph != one file. It's a groups of files for all graphs in the
dataset. A named graph is a view of the quad table.
Besides the window issue unix systems aren't happy either if they have to
keep unsued filehandler open.
If you flush the cache, the database is closed.
Outside testing, don't delete a database while running.
So in tests there's apossibility I can remove the database files?
Yes - the TDB test suite does - on Windows it creates a new directory for
each test using a unique name generator. They go away when the JVM exits
but only then.
Seems to be the only way. Tried flushing the dataset, the graph, deleting
all the triples yet the files remain in use.
Deleting the graph is removing from the quad table. The database is
separate from the view (graph). With transactions changes, especially
many small transactions, get batched up so that changes can actually
happen faster than non-transaction mode.
Andy
Changing the filemode in a static initializer seems to do the trick. Not
sure what the performance implications are. But for perfromance the
SingleTdbDatasetTcProvider should be used anyway.
Cheers,
Reto
