Pieter, do you know how Neo4j handles ResourceIterator with respect to closing a Graph. If I'm iteratng ResourceIterator and another thread calls Graph.close() what happens?
On Wed, Oct 7, 2015 at 7:35 AM, pieter-gmail <[email protected]> wrote: > Hi, > > The resource that concerns me most is GraphTraversal as that is almost > always a resource to the underlying db and is created very very often. I > reckon GraphTraversal should also implement AutoCloseable. Further, it > can be auto closed when fully iterated/traversed, for transactional > graphs on commit/rollback or by the user. > > For long running transactions and for GraphTraversals that are not fully > traversed the user can manage the resource by closing it. > > This is similar to how Neo4j does it with its ResourceIterator which is > an AutoCloseable > > Thanks > Pieter > > On 05/10/2015 21:56, Stephen Mallette wrote: > > There are two tickets in JIRA that relate to the semantics of closing and > > releasing resources in the Graph hierarchy: > > > > + Graph > > + TraversalSource > > + TraversalStrategy > > + GraphTraversal > > + Transaction > > > > https://issues.apache.org/jira/browse/TINKERPOP3-789 > > https://issues.apache.org/jira/browse/TINKERPOP3-790 > > > > There's been some discussion on them already. I bring this to everyone's > > attention as the change could have wide repercussions depending on the > > direction it goes. The short of the matter is that currently: > > > > 1. Graph implements AutoCloseable, but we don't enforce the notion of > > close() itself in the test suite. > > 2. TraversalSource should likely implement AutoCloseable as there are > > sometimes resources that need to be released when a TraversalSource is no > > longer in use. > > 3. Transaction implements AutoCloseable but it applies in the context of > > how a Transaction will behave when Graph.close() is called. > > > > Where is this all going? Matt Frantz summarized the thought points > nicely > > in this comment: > > > > > https://issues.apache.org/jira/browse/TINKERPOP3-790?focusedCommentId=14710389&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14710389 > > > > Basically, there's two options Matt identified: > > > > 1. Making it so that Graph.close() would release resources and > effectively > > close() all things it spawned is one approach, but I''m not sure how > > straightforward/practical to implement that is. I suspect it will > > complicate Graph implementations as well. > > 2. The alternative is that the things in this hierarchy can have their > own > > expensive resources which can be independently closed. I think that this > > approach more closely fits with the code as we have it now and won't > unduly > > burden implementers. TinkerPop Developers will have to know when to call > > close() (e.g. if a TraversalStrategy has expensive resources and the user > > assumes that a call to TraversalSource.close() will release those > > resources, then they might be wrong - depends on the approach we decide > > on). > > > > When I first created 790, i had the second option in mind, but since Matt > > brought wrote that comment, i figured it was worth thinking through as a > > whole. > > > > Once that is decided then we should figure out 789 which is how to > enforce > > the semantics of close() (e.g. what does a Graph do when it's closed and > > someone calls graph.traversal()?). > > > > Thoughts? > > > >
