I have written a locking graph that wraps a delegate and locks
operations appropriately.
Since unclosed iterators were obviously going to be an issue I do some
GC tricks with a callback on a reference queue after the iterator is
garbage collected to verify that close is in fact called, and if not to
break the read lock that is still held.
Using an optional (and very slow) flag to create an exception when the
iterator is constructed I have detected many unclosed iterators in our
own code, and I think those two in the Jena code base.
While a DB graph is perhaps less catastrophic in its behavior on
unclosed iterators, it is nevertheless an issue.
Jeremy
On 8/16/2012 8:11 AM, Andy Seaborne wrote:
Re: unclosed iterator in ResourceImpl.getPropertyResourceValue()
Re: MultiUnion multiGraphFind - closing iterators after exception
Jeremy,
Could you give some background? closing of iterators has always been
a bit tricky (because the reality is enough application code doesn't
that we say all we like about "must close unfinished" - it is not
going to happen).
In what circumstances does it matter to your code that unfinished
iterators do get cleanly closed? What's the environment?
Andy
