Ken Hu created TINKERPOP-3287:
---------------------------------
Summary: Failed commit retains opened UnmanagedTransaction
Key: TINKERPOP-3287
URL: https://issues.apache.org/jira/browse/TINKERPOP-3287
Project: TinkerPop
Issue Type: Bug
Components: server
Affects Versions: 4.0.0
Reporter: Ken Hu
When {{tx.commit()}} fails due to an optimistic-locking conflict, the
underlying graph transaction may roll back and close itself. Gremlin Server
nevertheless leaves the associated {{UnmanagedTransaction}} registered because
{{handleGraphOp()}} only invokes {{close(true)}} after a successful commit.
This creates a half-closed transaction:
- The client’s follow-up {{tx.rollback()}} returns HTTP 404 because the
underlying graph transaction is already closed.
- The {{UnmanagedTransaction}} remains in {{{}TransactionManager{}}},
retaining a {{maxConcurrentTransactions}} slot, executor thread, and idle timer.
- Resources are released only when the idle timeout expires.
Under sustained write contention, conflict-losing commits can temporarily
exhaust transaction slots and executor threads. The observed “transactions
timed out after 30000 ms of inactivity” messages were leaked conflict losers
rather than abandoned client transactions.
Root cause:
{code:java}
graphOp.accept(graph.tx()); // may throw
transactionManager.get(transactionId).ifPresent(tx -> tx.close(true));
{code}
If {{commit()}} throws, wrapper cleanup is skipped.
Expected behavior:
After a failed commit, Gremlin Server should promptly reclaim the wrapper when
the underlying graph transaction is closed. If a provider leaves the graph
transaction open after failure, the server may retain it so the client can
attempt rollback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
