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

[jira] [Commented] (TINKERPOP3-739) Transaction Retry as Part of Gremlin Server Transaction Management

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

Dylan Millikin commented on TINKERPOP3-739:
-------------------------------------------

Following up on the discussion in TINKERPOP3-741. 

For regular queries, should we perhaps allow for an extra argument in the message payload that would apply a retry strategy? Something along the lines of:
{code}
{ 
    "op": "eval",
    "processor": "",
    "args":{
        "retry":{"strategy":"exponentialBackoff", "value":10}
    }
}
{code}

The server would then decide to run this script in {{submit()}}.


For in-session fail-retry strategies things get a little complicated, seeing as this is one of the final sticking points for us to start entering production on some of our smaller clients I'd like to offer a few ideas to see if something (or anything) can be done server end.

Here are some ideas, not all are good or feasable, etc.. but hopefully they trigger some sort of an idea, or partial support that would help clients with a client side fail-retry strategy:
- Use the mutationListener to build a delta. Then reapply that delta.
- Keep a reference to the local graph and extract a delta from it on failure. reapply that delta.
- Allow the drivers to send specific "transaction" queries and intelligently recreate a delta from that.

I think the main issue with dealing with this server side is the following scenario:

- query #1 : {{graph.addVertex()}}
- query #2 : {{graph.addVertex()}}
- query #3 : {{g.V(1).addOutEdge("label", 2)}} where 1 and 2 are vertices fetched by using the IDs returned in the first two queries.

On a retry those IDs will be invalid and I don't really know if there's any decent way of dealing with this. 


> Transaction Retry as Part of Gremlin Server Transaction Management
> ------------------------------------------------------------------
>
>                 Key: TINKERPOP3-739
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-739
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.0.1-incubating
>            Reporter: stephen mallette
>            Assignee: stephen mallette
>            Priority: Minor
>
> Consider a means to configure automated transaction retry as part of the transaction management function of Gremlin Server.



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