This is an automated email from the ASF dual-hosted git repository. spmallette pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tinkerpop.git
commit c4557a657a83c872da1ef6fe25f1c46f15ff3b75 Author: Stephen Mallette <[email protected]> AuthorDate: Thu Jul 3 09:58:49 2025 -0400 Clarified docs around fail() and transactions CTR --- docs/src/reference/gremlin-applications.asciidoc | 4 ++++ docs/src/reference/implementations-tinkergraph.asciidoc | 2 +- docs/src/reference/the-traversal.asciidoc | 8 ++++++++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/src/reference/gremlin-applications.asciidoc b/docs/src/reference/gremlin-applications.asciidoc index b89d9835cb..0eee376fab 100644 --- a/docs/src/reference/gremlin-applications.asciidoc +++ b/docs/src/reference/gremlin-applications.asciidoc @@ -2594,6 +2594,10 @@ Gremlin Server performs automated transaction handling for "sessionless" request for "in-session" requests with that feature enabled. It will automatically commit or rollback transactions depending on the success or failure of the request. +IMPORTANT: Understand the transactional capabilities of the graph configured in Gremlin Server when using sessions. For +example, a basic `TinkerGraph` in its non-transactional form won't be able to rollback a failed traversal, therefore it +is quite possible to get partial updates if the first part of a traversal succeeds and the rest fails. + 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. The aliases are then used to determine which graphs will have their transactions closed for that request. Running diff --git a/docs/src/reference/implementations-tinkergraph.asciidoc b/docs/src/reference/implementations-tinkergraph.asciidoc index 592adff319..ecd43faede 100644 --- a/docs/src/reference/implementations-tinkergraph.asciidoc +++ b/docs/src/reference/implementations-tinkergraph.asciidoc @@ -263,7 +263,7 @@ public class GraphService { // to run in a variety of scenarios. here we decide that TinkerTransactionGraph is a // suitable test graph replacement for our actual production graph. public class GraphServiceTest { - private static final TinkerTransactionGraph graph = TinkerTransactionGraph().open(); + private static final TinkerTransactionGraph graph = TinkerTransactionGraph.open(); private static final GraphTraversalSource g = traversal.withEmbedded(graph); private static final GraphService service = new GraphService(g); diff --git a/docs/src/reference/the-traversal.asciidoc b/docs/src/reference/the-traversal.asciidoc index 70f3647b85..5be99761e8 100644 --- a/docs/src/reference/the-traversal.asciidoc +++ b/docs/src/reference/the-traversal.asciidoc @@ -1657,6 +1657,14 @@ Metadata > {} The code example above exemplifies the latter use case where there is essentially an assertion that there is a vertex with a particular "name" value prior to updating the property "k" and explicitly failing when that vertex is not found. +The `fail()` step does not guarantee that mutations are not partially applied. Triggering `fail()` produces an +exception, but it's effect on any open transactions or the underlying graph's behavior ends there. Generally speaking, +mutations made to the point of `fail()` being triggered are applied and `fail()` itself has no influence on rolling back +those changes. It is up to the application catching that exception to act in a fashion that will allow for that +rollback. Moreover, the ability to rollback at all is graph provider dependent. For example, a basic TinkerGraph, +configured without transaction support, will simply be left in a partially mutated state whether the action to rollback +on `fail()` was implemented or not. + *Additional References* link:++https://tinkerpop.apache.org/javadocs/x.y.z/core/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.html#fail()++[`fail()`],
