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?
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.