I've created this issue for tracking:
https://issues.apache.org/jira/browse/TINKERPOP-2537
and have pushed a branch for early review:
https://github.com/apache/tinkerpop/tree/TINKERPOP-2537
The server-side is a bit of a copy/paste mess at the moment, so try not to
pay attention there too much a
Stephen Mallette created TINKERPOP-2537:
---
Summary: Support bytecode based requests in sessions and remote
tx()
Key: TINKERPOP-2537
URL: https://issues.apache.org/jira/browse/TINKERPOP-2537
Proje
First of all, I managed to fumble my last code sample - sorry. You can
either use the Transaction object explicitly like this:
g = traversal().withRemote(conn)
tx = g.tx() // Transaction object
gtx = tx.begin() // GraphTraversalSource
assert tx.isOpen() == true
gtx.addV('person').iterate()
gtx.ad
>
> I suppose the
> question is how would we ensure that each request for a session ends up
> being executed on the same thread from the previous request if jobs are
> randomly submitted to a worker pool?
I haven't thought through the details, but on top of my head, we would have
to maintain some
I started a fresh thread for this topic Divij brought up, with more context:
> In a scenario where we have both
> session-less and sesion-ful requests being made to the server, the
resource
> allocation will not be fair and may lead to starvation for some requests.
> This problem exists even today
Great idea Stephen. I agree with standardizing the explicit transaction
semantics in cases of remote server (implicit aka sessionless is already
self explanatory) and unifying the syntax with embedded graph usage.
Couple of notes:
1. I would favor the begin() instead of create() as it's closer to
The Transaction object is a bit important with remote cases because it
holds the reference to the session. With embedded use cases we generally
adhere to ThreadLocal transactions so the Transaction implementation in
that case is more of a controller for the current thread but for remote
cases the T
[
https://issues.apache.org/jira/browse/TINKERPOP-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304196#comment-17304196
]
ASF GitHub Bot commented on TINKERPOP-2531:
---
radu-iviniciu commented on pul
> We should just communicate clearly that a simple remote traversal already
uses a transaction by default,
That's a good point because even with this change we still have a situation
where a single iterated remote traversal will generally mean a server
managed commit/rollback, but in embedded mode
I like the idea of adding transactions for remote traversals as they close a
gap in functionality that we currently have for remote traversals. We should
just communicate clearly that a simple remote traversal already uses a
transaction by default, meaning that the server will roll back any chan
10 matches
Mail list logo
