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?

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

Goal

Constraints and uncertainty

Questions

0 answers

Your perspective belongs here.

0 question comments