This is an automated email from the ASF dual-hosted git repository.

kenhuuu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tinkerpop.git

commit ca05acf3dbf9beaed0f2c938ee599207e303f081
Author: Ken Hu <[email protected]>
AuthorDate: Tue Mar 31 17:43:13 2026 -0700

    Update beta warnings in documentation CTR
---
 docs/src/dev/developer/for-committers.asciidoc   |  2 +-
 docs/src/reference/gremlin-applications.asciidoc | 40 +++++++++++++++---------
 docs/src/reference/gremlin-variants.asciidoc     |  2 +-
 docs/src/reference/intro.asciidoc                |  2 +-
 4 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/docs/src/dev/developer/for-committers.asciidoc 
b/docs/src/dev/developer/for-committers.asciidoc
index 7101836c90..fa22fed4fa 100644
--- a/docs/src/dev/developer/for-committers.asciidoc
+++ b/docs/src/dev/developer/for-committers.asciidoc
@@ -664,7 +664,7 @@ configured by `CucumberOptions` on "*FeatureTest" setups.
 [[gremlin-socket-server-tests]]
 === Gremlin Socket Server Tests
 
-IMPORTANT: 4.0.0-beta.1 Release - Removes websockets. This section will be 
updated as the new HTTP test server falls into place.
+IMPORTANT: 4.0.0-beta.2 Release - Removes websockets. This section will be 
updated as the new HTTP test server falls into place.
 
 `gremlin-socket-server` is an included test server for driver tests which 
require predefined server
 behavior. Typically, this is to test scenarios such as the server closing the 
connection or returning
diff --git a/docs/src/reference/gremlin-applications.asciidoc 
b/docs/src/reference/gremlin-applications.asciidoc
index b65b9c58ee..b825d456c2 100644
--- a/docs/src/reference/gremlin-applications.asciidoc
+++ b/docs/src/reference/gremlin-applications.asciidoc
@@ -1306,7 +1306,7 @@ is hardly feasible, because such requests get full access 
to Gremlin Server's ex
 execution of `GraphFactory.open()` or `GraphTraversalSource.getGraph()` 
methods without resorting to TinkerPop
 implementation details (that is, internal API's that can change without 
notice).
 
-IMPORTANT: 4.0.0-beta.1 Release - These authorization mechanisms don't 
currently apply due to the removal of Bytecode.
+IMPORTANT: 4.0.0-beta.2 Release - These authorization mechanisms don't 
currently apply due to the removal of Bytecode.
 
 The three mechanisms for authorization each have their merits in terms of 
simplicity and flexibility. The table below
 gives an overview.
@@ -1339,7 +1339,7 @@ such as read only access can be either applied at 
authorization time as policy i
 execution time as a result of an applied `Strategy` (denoted as 'hybrid' 
bytecode analysis in the table). A code
 example pursuing the former option is provided in the <<authz-code-example, 
next section>>.
 
-IMPORTANT: 4.0.0-beta.1 Release - passive and active authorization mechanisms 
are not supported in this beta
+IMPORTANT: 4.0.0-beta.2 Release - passive and active authorization mechanisms 
are not supported in this beta
 because bytecode has been replaced with GremlinLang.
 
 NOTE: Gremlin Server is not shipped with `Authorizer` implementations, because 
these would heavily depend on the external
@@ -2114,21 +2114,33 @@ above with the use of the `maximumSize`.
 [[considering-transactions]]
 ==== Considering Transactions
 
-Gremlin Server performs automated transaction handling for "sessionless" 
requests (i.e. no state between requests) and
-for "in-session" requests with that feature enabled. It will automatically 
commit or rollback transactions depending
-on the success or failure of the request.
+Non-transactional requests (those without a `transactionId`) behave as 
self-contained units of work where the graph's
+own transaction semantics apply. Each traversal executes within its own 
transaction as managed by the graph
+implementation itself. Transactional requests participate in a transaction 
opened via `g.tx().begin()`, where the
+client explicitly controls the lifecycle through `g.tx().commit()` and 
`g.tx().rollback()`.
 
-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.
+IMPORTANT: Understand the transactional capabilities of the graph configured 
in Gremlin Server. For example, a basic
+`TinkerGraph` does not support transactions. Use `TinkerTransactionGraph` or 
another transaction-capable graph
+implementation. Attempting to begin a transaction on a non-transactional graph 
will result in an error.
 
-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
-Gremlin Server in this configuration should be more efficient when there are 
multiple graphs being hosted as
-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.
+Two settings in the Gremlin Server YAML control transaction resource usage:
 
+* `transactionTimeout` (default: 600000ms) -- How long a transaction can sit 
idle before the server forcibly rolls it
+  back. The timeout resets on each request received for that transaction.
+* `maxConcurrentTransactions` (default: 1000) -- The maximum number of open 
transactions allowed. When the limit is
+  reached, new begin requests are rejected with HTTP 503.
+
+Each open transaction consumes a dedicated thread on the server to maintain 
thread-local transaction state for the
+underlying graph. Ensure that clients close transactions promptly and that the 
`transactionTimeout` is set to reclaim
+abandoned ones. The `transactions` gauge metric can be used to monitor usage.
+
+In load-balanced deployments, all requests within a transaction must reach the 
same server instance because
+transaction state is local to the server that created it. The 
`X-Transaction-Id` header is available for load
+balancers to implement sticky routing without parsing the request body. A 
transactional request that arrives at the
+wrong server receives a 404 response.
+
+A failed traversal within an open transaction does not cause the server to 
close or rollback the transaction. The
+transaction remains open until the client explicitly commits, explicitly rolls 
back, or the idle timeout fires.
 
 [[request-retry]]
 ==== Request Retry
diff --git a/docs/src/reference/gremlin-variants.asciidoc 
b/docs/src/reference/gremlin-variants.asciidoc
index bc521097fa..35f189b0db 100644
--- a/docs/src/reference/gremlin-variants.asciidoc
+++ b/docs/src/reference/gremlin-variants.asciidoc
@@ -913,7 +913,7 @@ Remote systems like Gremlin Server and Remote Gremlin 
Providers respond to reque
 format and respond by serializing results to some format to be interpreted by 
the client. For JVM-based languages,
 there is a single option for serialization: GraphBinary.
 
-IMPORTANT: 4.0.0-beta.1 Release - There is temporary support for GraphSON in 
the Java driver which will help with
+IMPORTANT: 4.0.0-beta.2 Release - There is temporary support for GraphSON in 
the Java driver which will help with
 testing, but it is expected that the drivers will only support GraphBinary 
when 4.0 is fully released.
 
 It is important that the client and server have the same serializers 
configured in the same way or else one or the
diff --git a/docs/src/reference/intro.asciidoc 
b/docs/src/reference/intro.asciidoc
index 6822b25ceb..58fe92497d 100644
--- a/docs/src/reference/intro.asciidoc
+++ b/docs/src/reference/intro.asciidoc
@@ -424,7 +424,7 @@ has two such formats that it uses with 
link:https://tinkerpop.apache.org/docs/x.
 link:https://tinkerpop.apache.org/docs/x.y.z/dev/io/#graphson[GraphSON]. Users 
should prefer GraphBinary when available
 in the programming language being used.
 
-IMPORTANT: 4.0.0-beta.1 Release - There is temporary support for GraphSON in 
the Java driver which will help with
+IMPORTANT: 4.0.0-beta.2 Release - There is temporary support for GraphSON in 
the Java driver which will help with
 testing, but it is expected that the drivers will only support GraphBinary 
when 4.0 is fully released.
 
 A good example is the `subgraph()`-step which returns a `Graph` instance as 
its result. The subgraph returned from

Reply via email to