You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Mike Personick (JIRA)" <ji...@apache.org> on 2015/12/21 16:28:46 UTC

[jira] [Commented] (TINKERPOP-790) Implement AutoCloseable on TraversalSource

    [ https://issues.apache.org/jira/browse/TINKERPOP-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066570#comment-15066570 ] 

Mike Personick commented on TINKERPOP-790:
------------------------------------------

I feel very strongly that any open-ended result sets provided by the graph must be assumed to be backed by a database resource that needs to be closed.  It's true for Blazegraph and it will certainly be true for others.  When you ask for a tuple iterator on a database you must close it, and that is what asking for an iterator over edges, vertices, properties is.  Furthermore, closing the tuple iterator does not close your connection to the database or close the database - these things might be backed by different resources that are shared across queries or across connections.  If you ask for a query result iterator, you close it when you're done with it.  If you ask for a connection to the database, you close it when you're done with it.  If you open a handle to the database itself, you close it when you're done with it.  Closing has a cascading effect down that hierarchy, but not up (closing a connection will close and result set iterators associated with that connection but will not close the database itself).

This is an issue in the Graph API, where many methods return simple Iterators, which are not AutoCloseable.  Materializing the result set from a call to vertices() or edges() fully into memory first to manage this problem is not a viable solution for a large graph.  For Blazegraph, I hid a close() inside the last call to next(), but this does not protect callers that do not fully drain the iterator.  Using GC/finalization to manage these resources is definitely not a viable solution.

I have not looking at TraversalStrategy yet but I assume it will present a similar problem.

> Implement AutoCloseable on TraversalSource
> ------------------------------------------
>
>                 Key: TINKERPOP-790
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-790
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.2-incubating
>            Reporter: stephen mallette
>            Assignee: stephen mallette
>             Fix For: 3.2.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)