GitHub user spmallette opened a pull request:
https://github.com/apache/incubator-tinkerpop/pull/198
TINKERPOP-1035 Better Consistency in Gremlin Server Transaction Management
https://issues.apache.org/jira/browse/TINKERPOP-1035
A second set of improvements on the transaction management system. This
round of changes undoes some of the work previously entered for this ticket as
the concepts weren't as sound as they should have been. In this PR, I've
removed some of the special handling traversals had which I think would have
confused people and pushed serialization more cleanly into the
`GremlinExecutor` which ensure that it occurs in the same thread of execution
as the original transaction. This prevents "extra" transactions from being
opened which could be problematic for graphs that incur "high" expense for that
activity. In another attempt to ensure that transactions were more tightly
controlled, I always checked for an open transaction before actually issuing a
commit/rollback.
Tested with:
```text
mvn clean install && mvn verify -DskipIntegrationTests=false -pl
gremlin-server
```
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-tinkerpop TINKERPOP-1035
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-tinkerpop/pull/198.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #198
----
commit dc48957cc06e6d5bd3b3ad500b47d117dcc3cc3a
Author: Stephen Mallette <[email protected]>
Date: 2015-12-15T23:00:27Z
Altered transaction management in Gremlin Server
Removed the approach that did a commit prior to iteration and serialization
as this opened a new transaction and wasn't optimal. Instead, introduced a
Frame abstraction that allowed serialization to occur during iteration of
results. In this way, results could be serialized in the same thread (and thus
the same transaction) and errors in some graphs could be avoided. The commit
now occurs after the last item is serialized in the result set. The last
message is only flushed to the client after the commit occurs which assures
that the the client shouldn't be able to send it's next request prior to that
one being fully done.
commit f81d5c4c194c7c25bb2125cc0ed1179f80ad5dd5
Author: Stephen Mallette <[email protected]>
Date: 2015-12-16T11:01:42Z
Updated documentation around transaction management.
commit 0b9556d8e3e2b025103564ba2e57dc128583f18e
Author: Stephen Mallette <[email protected]>
Date: 2015-12-16T15:18:54Z
Deprecated some old handlers in Gremlin Server.
No one should be using these directly but as they are public, it felt
better to just deprecate for now.
commit f34bde7a98b98f013f9bface26fe449197aece0d
Author: Stephen Mallette <[email protected]>
Date: 2015-12-16T16:29:09Z
Check for open transactions before doing an auto commit/rollback.
By adding this check Gremlin Server only commits/rollsback at the start of
a request or at the error driven end of a request. This should prevent graphs
from creating extra transactions when they are not needed (which might be
expensive to do for some graphs).
commit bc1fc5e8931472a9c41b46dce03848a30cd7d59b
Author: Stephen Mallette <[email protected]>
Date: 2015-12-16T16:57:45Z
Deprecate local error metric in Gremlin Server
The local error metric was double counting errors as there was already a
global error catching such things. Deprecated in case someone had extended
these two classes and was using that class somehow.
commit 0e2700508774b807da209109bf305268e7a1b0d7
Author: Stephen Mallette <[email protected]>
Date: 2015-12-29T18:50:40Z
Merge remote-tracking branch 'origin/master' into TINKERPOP-1035
commit 58cd80672c036f5b4eeab54e007627ca12c47800
Author: Stephen Mallette <[email protected]>
Date: 2016-01-09T17:23:20Z
Used a independent loop control for result interation.
This solves a problem where a graph could automatically open a new
transaction on the same request. In the result iteration loop, a commit gets
called if there are no results left, when the loop traverse back to the top of
the while() to exit, it does a final check to Traversal.hasNext(). On some
graphs, automatic transaction handling could open a new transaction there.
subtle - oh so subtle.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
