Driver-enforced transaction timeout vs explicit cancel API: which provides predictable rollback semantics for long-running write transactions?

Question

GoalSelect a cancellation strategy for long-running Cypher write transactions that guarantees uncommitted changes are rolled back before any partial writes become visible, while avoiding the ambiguity where a cancellation error is returned even after a commit has succeeded.Constraints and uncertaintyTransactionConfig.withTimeout(Duration) is enforced client-side; if the server is slow or unreachable the timeout may not fire until a response arrives, potentially extending the wait beyond the configured duration.Explicit Result.cancel() or Session.cancel() requires the Result object to stay alive; a cancelled session that has already been closed or garbage-collected leaves the server-side query running.Neither approach documents whether rollback occurs before or after partial writes are applied. Server logs show only "Query cancelled" without indicating whether the transaction had been partially committed.If a transaction has already committed, the driver still surfaces a cancellation error, making it impossible to distinguish "rolled back" from "committed then cancelled" from the client side alone.QuestionsDoes TransactionConfig.withTimeout() guarantee that rollback completes before any partial writes are persisted, or can the timeout fire after a partial commit?When using Result.cancel(), is there a documented transaction lifecycle phase after which cancellation becomes a no-op because the commit has already been acknowledged?Can application logic reliably differentiate "cancelled before commit" from "cancelled after commit" given that both paths return a cancellation error?

Tasadduq Burney · Answer

To achieve predictable rollback semantics for long-running write transactions, the server-side transaction timeout (configured on the database) is generally more reliable, but neither method completely eliminates the ambiguity of the 'commit-cancel' error state.The core issue lies in the asynchronous nature of the driver-server communication. When a timeout occurs or a cancel is requested, the driver stops waiting for a response and returns an error. However, if the server has already moved to the commit phase, the changes will be persisted despite the driver's reported error.

Comparison of Timeout vs. Cancellation

TransactionConfig.withTimeout(): This is primarily a client-side enforcement. If the server is under load or the network hangs, the driver may time out on the client side, but the server might continue processing the query until it reaches its own internal timeout limit.
  Result.cancel() / Session.cancel(): This sends an explicit cancellation signal to the server. If the transaction has already reached the lifecycle phase where the commit is being acknowledged, the cancellation becomes a no-op on the server, yet the driver still surfaces a cancellation error.

The Ambiguity ProblemApplication logic cannot reliably differentiate between "rolled back before commit" and "cancelled after commit" using only the driver's exception types. Both paths result in a cancellation-related error because the driver cannot confirm the server-side state once it stops listening for results.

Recommended Strategy for Predictable Rollback

Use Server-Side Timeouts: Instead of relying solely on driver-side configuration, set a transaction timeout at the database level. This ensures the server itself terminates the work, regardless of the client's state.
  Implement Idempotency Keys: Since the error state is ambiguous, use unique transaction IDs in your writes. If a cancellation error occurs, query the database for that ID to determine if the write was actually persisted.
  Explicit Cancel for Cleanup: Use Result.cancel() when you need to stop a query early (e.g., a user closes a UI), but do not rely on it as the primary mechanism for data integrity.

Diagnostic Question: Are you using a clustered Neo4j environment or a standalone instance, as propagation lag can affect the visibility of partial writes after a timeout?

Driver-enforced transaction timeout vs explicit cancel API: which provides predictable rollback semantics for long-running write transactions?

Goal

Constraints and uncertainty

Questions

1 answer

To achieve predictable rollback semantics for long-running write transactions, the server-side transaction timeout (configured on the database) is generally more reliable, but neither method completely eliminates the ambiguity of the 'commit-cancel' error state.

Comparison of Timeout vs. Cancellation

The Ambiguity Problem

Recommended Strategy for Predictable Rollback

Your perspective belongs here.

0 question comments