[
https://issues.apache.org/jira/browse/TINKERPOP3-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP3-704:
----------------------------------------
Fix Version/s: 3.0.0.GA
As it stands, the user needs to be responsible for self-iterating traversals
that mutate the graph so that the script is properly executed within the same
transaction. For example, one would expect to send:
{code}
x=g.addV().next();g.V(4216).addOutE("knows",x)
{code}
and have the newly created "out edge" returned. However, what happens there in
sessionless requests is that the script evaluates to an {{Iterator}} which is
iterated to results in a possibly different thread. If it happens as such,
weirdness ensues as the thread-local nature of a transaction gets leaked.
Technically, the script should have been submitted as:
{code}
x=g.addV().next();g.V(4216).addOutE("knows",x).next()
{code}
Gremlin Server could change to support iteration in the same thread as the
script evaluation, but if that happens then users may still get weirdness (e.g.
temporary ids in certain {{Graph}} implementations) in their iterated results
as the transaction is not yet committed. Which would mean that in such cases
they would have to send their script as:
{code}
x=g.addV().next();e=g.V(4216).addOutE("knows",x).next();graph.tx().commit();e
{code}
or something similar (again - depending on the graph).
thinking...................
> Better Encapsulate Gremlin Server Requests Around Transactions
> --------------------------------------------------------------
>
> Key: TINKERPOP3-704
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-704
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: server
> Reporter: stephen mallette
> Assignee: stephen mallette
> Fix For: 3.0.0.GA
>
>
> See:
> https://github.com/thinkaurelius/titan/issues/1095
> for more information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
