[
https://issues.apache.org/jira/browse/TINKERPOP3-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14710389#comment-14710389
]
Matt Frantz commented on TINKERPOP3-790:
----------------------------------------
*Decide which of the objects will be responsible for others.*
What is the lifecycle of a {{GraphTraversal}} that I create from a
{{GraphTraversalSource}}? Am I allowed to {{close}} the
{{GraphTraversalSource}} but still use the {{GraphTraversal}}? Or is there a
parent-child relationship?
*Identify reusable objects in many-to-many relationships.*
Can I configure and install a single {{TraversalStrategy}} instance on multiple
{{Traversal}} instances?
---
A lifecycle hierarchy would be easier for developers to reason about, even if
it is not as flexible as other lifecycle schema. The idea would be that
calling {{close}} on something higher in the hierarchy will close everything
below it, and render any subsequent API calls on closed objects as
"unsupported" or "undefined" behavior. Could the hierarchy be something like
this?
* {{Graph}}
* {{GraphTraversalSource}}
* {{TraversalStrategy}}
* {{GraphTraversal}}
* {{Transaction}}
Removing something, e.g. {{TraversalStrategy}} or {{Transaction}}, from the
hierarchy would open up new use cases, at the expense of increasing the
behavior surface area and complicating the rules that developers must follow
regarding when to call {{close}}.
Moving a closable API up or down within the hierarchy would result in an
equally complex hierarchy, albeit one with different use cases.
Using a schema other than a hierarchy means that developers would be encouraged
to call {{close}} more often, as each independently closable thing is allowed
to have expensive resources.
A developer can choose to allow GC to {{close}} its resources, but that choice
can lead to more surprising behavior resulting from the nondeterminism of GC,
dynamic vendor implementations, new vendor versions, and cross-vendor skew.
> Implement AutoCloseable on TraversalSource
> ------------------------------------------
>
> Key: TINKERPOP3-790
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-790
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: stephen mallette
> Assignee: Marko A. Rodriguez
> Fix For: 3.1.0-incubating
>
>
> A {{TraversalSource}} may have resources to release so having a {{close}}
> method would allows that release to occur. The specific case has to do with
> {{EventStrategy}} which registers a listener on {{Transaction}}. That
> listener should be removed when the user is done with the
> {{TraversalSource}}, but there is currently no way to clean that up. The
> calling of {{close}} should prevent future traversals from that
> {{TraversalSource}}.
> I suppose this also means that a {{TraversalStrategy}} will need to
> optionally implement {{AutoCloseable}} or some other marker interface to
> designate it as a strategy that needs to release resources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
