You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2015/12/09 17:35:11 UTC

[jira] [Closed] (TINKERPOP-1035) Better Consistency in Gremlin Server Transaction Management

     [ https://issues.apache.org/jira/browse/TINKERPOP-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stephen mallette closed TINKERPOP-1035.
---------------------------------------
    Resolution: Implemented

> Better Consistency in Gremlin Server Transaction Management 
> ------------------------------------------------------------
>
>                 Key: TINKERPOP-1035
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1035
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.1.0-incubating
>            Reporter: stephen mallette
>            Assignee: stephen mallette
>             Fix For: 3.1.1-incubating
>
>
> For sessionless requests, Gremlin Server currently calls commit after iteration of results is complete.  The problem is that if the user issues: {{g.addV()}} then a graph may not have assigned proper identifiers at that point (or have other issues) at the time of serialization.  Gremlin Server also then spends time sending back results (if it can) when a call to {{commit()}} will ultimately fail.
> A solution that seems to work is to move the {{commit()}} to occur after eval but before iteration of results to the client.  Moreover, if the result to be iterated is a {{Traversal}} then we can check if it has {{Mutating}} steps and if so, iterate it out first to {{List}}, call {{commit()}} and then iterate the {{List}}.  The obvious downside is that we lose streaming in these cases as the result has to be held in memory.  
> For now, I think we need to take the downside as there aren't any other solutions that work consistently across all graphs.  For 3.2.x and forward we can think of better fixes that might introduce some breaking change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)