[2/9] incubator-tinkerpop git commit: Updated documentation around transaction management.

[sp...@apache.org]

Updated documentation around transaction management.


Project: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/commit/f81d5c4c
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/tree/f81d5c4c
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/diff/f81d5c4c

Branch: refs/heads/master
Commit: f81d5c4c194c7c25bb2125cc0ed1179f80ad5dd5
Parents: dc48957
Author: Stephen Mallette <sp...@genoprime.com>
Authored: Wed Dec 16 06:01:42 2015 -0500
Committer: Stephen Mallette <sp...@genoprime.com>
Committed: Wed Dec 16 06:01:42 2015 -0500

----------------------------------------------------------------------
 .../src/reference/gremlin-applications.asciidoc | 26 ++------------------
 .../upgrade/release-3.1.x-incubating.asciidoc   | 14 +----------
 2 files changed, 3 insertions(+), 37 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/f81d5c4c/docs/src/reference/gremlin-applications.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/reference/gremlin-applications.asciidoc b/docs/src/reference/gremlin-applications.asciidoc
index 96e25d7..7c1f83a 100644
--- a/docs/src/reference/gremlin-applications.asciidoc
+++ b/docs/src/reference/gremlin-applications.asciidoc
@@ -1193,25 +1193,8 @@ necessary for a given use case.
 Considering Transactions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Gremlin Server does automated transaction handling for "sessionless" requests (i.e. no state between requests). It
-will automatically commit or rollback transactions depending on the success or failure of the script. When submitting
-requests it is important to recognize that transaction management procedures may differ slightly depending on what is
-returned from the script.
-
-* If the script returns anything other than a `GraphTraversal`, a commit will be called just before results are
-iterated back to the client.
-* If the result is a `GraphTraversal` that has no `Mutating` steps, a commit will be called just before results are
-iterated back to the client.
-* If the result is a `GraphTraversal` that has one or more `Mutating` steps (i.e. one that modifies the `Graph`),
-the `GraphTraversal` will be iterated, it's results pushed to a `List`, commit called, and the result in the `List`
-iterated back to the client.
-
-The last bullet point above begs additional explanation.  Assume that the script `g.addV('name','stephen')` was
-submitted to the server.  That script returns a `GraphTraversal` and has a `Mutating` step. The traversal needs to
-be iterated in order for the mutations to take place or else the commit will have no effect. That's why Gremlin
-Server attempts to detect these types of traversals and treat them specially. The unfortunate downside is that the
-result of this script must be realized in memory which means that they aren't being streamed back to the client.
-For small results this likely should not present an issue.
+Gremlin Server performs automated transaction handling for "sessionless" requests (i.e. no state between requests). It
+will automatically commit or rollback transactions depending on the success or failure of the request.
 
 Another aspect of Transaction Management that should be considered is the usage of the `strictTransactionManagement`
 setting.  It is `false` by default, but when set to `true`, it forces the user to pass `aliases` for all requests.
@@ -1220,11 +1203,6 @@ Gremlin Server in this configuration should be more efficient when there are mul
 Gremlin Server will only close transactions on the graphs specified by the `aliases`. Keeping this setting `false`,
 will simply have Gremlin Server close transactions on all graphs for every request.
 
-NOTE: It is possible to bypass the transaction management system around `GraphTraversal` by using a lambda. Gremlin
-Server is only looking for `Mutating` steps, so a script like: `g.V().sideEffect{it.get().property('color','green')}`
-would not be iterated prior to commit and the mutations not realized.  If lambdas must be used then it is important
-to self-iterate by doing something like: `g.V().sideEffect{it.get().property('color','green')}.toList()`.
-
 Developing a Driver
 ~~~~~~~~~~~~~~~~~~~
 

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/f81d5c4c/docs/src/upgrade/release-3.1.x-incubating.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/upgrade/release-3.1.x-incubating.asciidoc b/docs/src/upgrade/release-3.1.x-incubating.asciidoc
index b50f3e1..c93495e 100644
--- a/docs/src/upgrade/release-3.1.x-incubating.asciidoc
+++ b/docs/src/upgrade/release-3.1.x-incubating.asciidoc
@@ -35,18 +35,7 @@ Upgrading for Users
 Gremlin Server Transaction Management
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-There were some changes to how Gremlin Server manages transactions on sessionless requests to make the process more
-consistent across different graph databases. Commits now occur after evaluation and prior to result iteration, which
-ensures an earlier failure (i.e. prior to results getting to the client indicating a false success) and better
-handling of a result that is a `GraphTraversal` that mutates the `Graph`.
-
-This change likely does not require any changes to the code of users, but does introduce some items to be aware of
-when issuing scripts. Most specifically, using lambdas in a request that returns a `GraphTraversal`, designed to modify
-the `Graph`, will fail to do so unless it is self-iterated.  In other words, instead of sending:
-`g.V().sideEffect{it.get().property('color','green')}` one would send:
-`g.V().sideEffect{it.get().property('color','green')}.toList()`
-
-In addition, Gremlin Server now has a new setting called `strictTransactionManagement`, which forces the user to pass
+Gremlin Server now has a setting called `strictTransactionManagement`, which forces the user to pass
 `aliases` for all requests. The aliases are then used to determine which graphs will have their transactions closed
 for that request. The alternative is to continue with default operations where the transactions of all configured
 graphs will be closed. It is likely that `strictTransactionManagement` (which is `false` by default so as to be
@@ -54,7 +43,6 @@ backward compatible with previous versions) will become the future standard mode
 it provides a more efficient method for transaction management.
 
 See: link:https://issues.apache.org/jira/browse/TINKERPOP-930[TINKERPOP-930],
-link:https://issues.apache.org/jira/browse/TINKERPOP-1035[TINKERPOP-1035],
 link:http://tinkerpop.apache.org/docs/3.1.1-incubating/#considering-transactions[Reference Documentation - Considering Transactions]
 
 Deprecated credentialsDbLocation