[
https://issues.apache.org/jira/browse/TINKERPOP3-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935025#comment-14935025
]
stephen mallette commented on TINKERPOP3-741:
---------------------------------------------
Thanks for thinking about this. I included "server" stuff here because I
thought there might be a way to unify transaction management for Gremlin Server
with the transaction retry stuff at the {{Graph}} level. I think I might have
been over-reaching. Maybe these should be two different issues (as they are now
with TINKERPOP3-739 in play). In other words, let's not convolute this
particular issue with Gremlin Server.
That said, I don't know how transaction retry fits for in-session transactions.
For sessionless, Gremlin Server does transaction management, so retry could be
baked in. For in-session, Gremlin Server does no transaction management - it
leaves it all to the client. Gremlin Server has no idea when the client is
calling {{commit()}} so it won't know if a retry is in order. Furthermore it
won't have the ability to know what to retry because on failure you have to
re-submit the entire transaction (and it has no record of what you submitted).
I'm not sure I see how this kind of thing will work server-side automatically -
thoughts?
> 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)
