Thanks for the thoughts, Bryn. sounds like you are of the opinion that we should maintain a strong hierarchy of close() not allowing other resources to live on.
The question is after calling close when how can you be sure that all > descendant resources are finished before returning to the user? Only by > keeping references to all spawned resources can you tell. > yeah - that's what complicates the implementations and i'm sorta not in favor of that, but that would be a proper implementation. > Perhaps Graph.close() should return a Future. That way you can block until > the graph is actually closed. a Future makes sense though that would be a separate method right? AutoCloseable.close() doesn't return Future. On Tue, Oct 6, 2015 at 9:15 AM, Bryn Cooke <[email protected]> wrote: > Hi, > > I'm not sure what the answer is here, > > What I am sure of is that the goal of close should be a graceful shutdown. > Once a resource is closed then it should not accept new requests. > Descendant resources may or may not continue to be operational, for > instance you may allow ongoing transactions to complete but that is > implementation dependent. > > The question is after calling close when how can you be sure that all > descendant resources are finished before returning to the user? Only by > keeping references to all spawned resources can you tell. > > Perhaps Graph.close() should return a Future. That way you can block until > the graph is actually closed. > > Bryn > > > > > > On 05/10/15 20: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? >> >> >
