You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/01/12 01:29:40 UTC

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

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

ASF GitHub Bot commented on TINKERPOP-1035:
-------------------------------------------

GitHub user spmallette opened a pull request:

    https://github.com/apache/incubator-tinkerpop/pull/198

    TINKERPOP-1035 Better Consistency in Gremlin Server Transaction Management

    https://issues.apache.org/jira/browse/TINKERPOP-1035
    
    A second set of improvements on the transaction management system.  This round of changes undoes some of the work previously entered for this ticket as the concepts weren't as sound as they should have been.  In this PR, I've removed some of the special handling traversals had which I think would have confused people and pushed serialization more cleanly into the `GremlinExecutor` which ensure that it occurs in the same thread of execution as the original transaction.  This prevents "extra" transactions from being opened which could be problematic for graphs that incur "high" expense for that activity.  In another attempt to ensure that transactions were more tightly controlled, I always checked for an open transaction before actually issuing a commit/rollback. 
    
    Tested with:
    
    ```text
    mvn clean install && mvn verify -DskipIntegrationTests=false -pl gremlin-server
    ```
    
    VOTE +1

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apache/incubator-tinkerpop TINKERPOP-1035

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-tinkerpop/pull/198.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #198
    
----
commit dc48957cc06e6d5bd3b3ad500b47d117dcc3cc3a
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-15T23:00:27Z

    Altered transaction management in Gremlin Server
    
    Removed the approach that did a commit prior to iteration and serialization as this opened a new transaction and wasn't optimal.  Instead, introduced a Frame abstraction that allowed serialization to occur during iteration of results.  In this way, results could be serialized in the same thread (and thus the same transaction) and errors in some graphs could be avoided.  The commit now occurs after the last item is serialized in the result set.  The last message is only flushed to the client after the commit occurs which assures that the the client shouldn't be able to send it's next request prior to that one being fully done.

commit f81d5c4c194c7c25bb2125cc0ed1179f80ad5dd5
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-16T11:01:42Z

    Updated documentation around transaction management.

commit 0b9556d8e3e2b025103564ba2e57dc128583f18e
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-16T15:18:54Z

    Deprecated some old handlers in Gremlin Server.
    
    No one should be using these directly but as they are public, it felt better to just deprecate for now.

commit f34bde7a98b98f013f9bface26fe449197aece0d
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-16T16:29:09Z

    Check for open transactions before doing an auto commit/rollback.
    
    By adding this check Gremlin Server only commits/rollsback at the start of a request or at the error driven end of a request. This should prevent graphs from creating extra transactions when they are not needed (which might be expensive to do for some graphs).

commit bc1fc5e8931472a9c41b46dce03848a30cd7d59b
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-16T16:57:45Z

    Deprecate local error metric in Gremlin Server
    
    The local error metric was double counting errors as there was already a global error catching such things. Deprecated in case someone had extended these two classes and was using that class somehow.

commit 0e2700508774b807da209109bf305268e7a1b0d7
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2015-12-29T18:50:40Z

    Merge remote-tracking branch 'origin/master' into TINKERPOP-1035

commit 58cd80672c036f5b4eeab54e007627ca12c47800
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2016-01-09T17:23:20Z

    Used a independent loop control for result interation.
    
    This solves a problem where a graph could automatically open a new transaction on the same request.  In the result iteration loop, a commit gets called if there are no results left, when the loop traverse back to the top of the while() to exit, it does a final check to Traversal.hasNext().  On some graphs, automatic transaction handling could open a new transaction there. subtle - oh so subtle.

----


> 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)