[
https://issues.apache.org/jira/browse/TINKERPOP3-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909100#comment-14909100
]
Dylan Millikin commented on TINKERPOP3-741:
-------------------------------------------
In light of the recent issues with titan I've decided that it would be best to
ensure that transaction handling on the client-server layer be as solid as
possible before pursuing those any further. Transaction retry strategies are an
important piece of that so I would love to get involved here.
This is also linked to TINKERPOP3-739 so there may be some overlap.
There is one issue with the current suggestion in this bug. (with respect to
Gremlin Server and in-session requests). The scripts submitted within the
transactions need to send results back to the client as they're being executed.
So we can't simply hold onto the scripts server side until the {{commit()}}
occurs.
I'm not sure if the workaround of both adding the scrips to a list and running
them at the same time would be an option because IDs would be reset between
attempts.
Ideally we would have something vaguely along the lines of:
{code}
public <R> Workload<R> submit();
public <R> Workload<R> submit(Graph work);
{code}
That would extract and hold onto the delta or some detached graph, allowing the
Workload to reapply it with every retry.
Again I don't know if this is possible as some vendors don't allow providing
IDs so the problem may remain the same. I don't have enough insight.
This could in turn be used for TINKERPOP3-739 and allowing for automatic 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.1-incubating
> Reporter: stephen mallette
> Assignee: stephen mallette
>
> 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)
