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

["stephen mallette (JIRA)" <ji...@apache.org>]

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

stephen mallette updated TINKERPOP-1035:
----------------------------------------
    Description: For sessionless requests to gremlin server, transactions management needs to be tightened such that serialization occurs in the same thread of execution as iteration.  This should ensure proper operation across different graphs providers (as some are more strict that others when it comes to transactions).  It will also ensure that "extra" transactions are not required to gather data for serialization purposes which should make requests more efficient.  Also, transaction management needs to better ensure that the commit of a successful request is complete before the client receives the final streamed message (seems like it was possible for a race condition there)  (was: 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.)

Made a number of edits to the description.  The old description provided for a working model that didn't quite work generically across all graph providers as original thought.  It also didn't do anything to make more efficient work of transactions.  This new better describes what needs to be done.

> 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 to gremlin server, transactions management needs to be tightened such that serialization occurs in the same thread of execution as iteration.  This should ensure proper operation across different graphs providers (as some are more strict that others when it comes to transactions).  It will also ensure that "extra" transactions are not required to gather data for serialization purposes which should make requests more efficient.  Also, transaction management needs to better ensure that the commit of a successful request is complete before the client receives the final streamed message (seems like it was possible for a race condition there)



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