[jira] [Updated] (TINKERPOP3-741) More Options For Transaction Retry

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

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

stephen mallette updated TINKERPOP3-741:
----------------------------------------
    Description: 
Submitting a transactional workload for automatic retry currently looks like this:

{code}
public <R> Workload<R> submit(final Function<Graph, R> work);
{code}

but that doesn't take into account relatively recent changes that allow mutation operations to execute over a {{Traversal}}.  It also doesn't account for workload constructed over multiple requests in a session to Gremlin Server too well.

Maybe we do something like:

{code}
public <R> Workload<R> submit(final Function<Graph, R>... work);
public <R> Workload<R> submit(final Function<TraversalSource, R>... work);
public <R> Workload<R> submit(final Traversal... work);
{code}

I suppose it might need to return a {{List<R>}} or something like that so that each piece of the transaction could maintain its own result.

With respect to Gremlin Server and in-session requests, a driver could automate transaction retry by inserting scripts to a list variable on the server side until client-side {{commit()}} at which point that list could be {{submit}} for retry.



  was:
Submitting a transactional workload for automatic retry currently looks like this:

{code}
public <R> Workload<R> submit(final Function<Graph, R> work);
{code>

but that doesn't take into account relatively recent changes that allow mutation operations to execute over a {{Traversal}}.  It also doesn't account for workload constructed over multiple requests in a session to Gremlin Server too well.

Maybe we do something like:

{code}
public <R> Workload<R> submit(final Function<Graph, R>... work);
public <R> Workload<R> submit(final Function<TraversalSource, R>... work);
public <R> Workload<R> submit(final Traversal... work);
{code}

I suppose it might need to return a {{List<R>}} or something like that so that each piece of the transaction could maintain its own result.

With respect to Gremlin Server and in-session requests, a driver could automate transaction retry by inserting scripts to a list variable on the server side until client-side {{commit()}} at which point that list could be {{submit}} for retry.




> More Options For Transaction Retry
> ----------------------------------
>
>                 Key: TINKERPOP3-741
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-741
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: structure
>    Affects Versions: 3.0.0-incubating
>            Reporter: stephen mallette
>            Assignee: Marko A. Rodriguez
>
> Submitting a transactional workload for automatic retry currently looks like this:
> {code}
> public <R> Workload<R> submit(final Function<Graph, R> work);
> {code}
> but that doesn't take into account relatively recent changes that allow mutation operations to execute over a {{Traversal}}.  It also doesn't account for workload constructed over multiple requests in a session to Gremlin Server too well.
> Maybe we do something like:
> {code}
> public <R> Workload<R> submit(final Function<Graph, R>... work);
> public <R> Workload<R> submit(final Function<TraversalSource, R>... work);
> public <R> Workload<R> submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List<R>}} or something like that so that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could automate transaction retry by inserting scripts to a list variable on the server side until client-side {{commit()}} at which point that list could be {{submit}} for retry.



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