To clarify: in this model, 'session' and 'tx' are essentially the same concepts.
I also think it is essential to have a common denominator that makes TP applications portable across implementations. That is why I also propose to restrict transaction scope to the thread scope. It will be a common denominator that will not harm user experience but will ensure uniform and expected API behavior. There should not be both `begin` and `open` methods because the contract of the beginning method is vague and unpredictable. On Tue, Dec 2, 2025 at 8:18 AM Andrii Lomakin <[email protected]> wrote: > Good day, > > I have a proposal to enhance the transaction handling logic in TP, > specifically regarding nested transaction calls, which are common in EE > development, particularly when utilizing OGM. > > Currently, calling open multiple times causes an exception. This behavior > is restrictive, and the term "open" can be confusing. > > I propose a design that improves the developer experience by using an > internal counter for transaction calls: > > Proposed transaction counter logic > 1. begin/commit counter: > - begin would increment an internal counter. > - commit would decrement the internal counter, causing the actual > transaction commit only when the counter reaches zero. > 2. rollback behavior: > - rollback would immediately force a transaction rollback and decrements > the internal counter > - the subsequent calls to rollback on the same transaction object should > be allowed until the stack trace reaches the initial begin method call, > after which further rollback calls would throw an exception. > 3. Error handling: > - A commit without a matching begin (e.g., counter is already zero) should > throw an exception. > - A rollback without a matching begin should throw an exception > > I would also consider hiding the Transaction object altogether and > delegating the logic of transaction management to GraphTraversalSource it > will simplify the API a lot, both for users and vendors. > > I also propose to restrict transaction scope to the thread scope, it will > be a common denominator that will not harm user experience but will ensure > uniform and expected API behavior across all implementations. > > Proposed API changes > - I propose deprecating open and using begin with the semantics described > above to avoid confusion. > - Transaction object is deprecated, and TX control functionality is > delegated to the GraphTraversal/Graph instances. > - tx() method is deprecated. > - Transaction scope is limited to the current thread only. > > Behavior for non-direct calls > When begin/commit/rollback methods are not called directly, the > transaction should be automatically committed by a terminal operation > (e.g., when hasNext returns false) in both remote and embedded modes. > > Implementation notes: > 1. The begin command should be added. Relying on the implicit start of TX > by traversal can lead to non-controlled side effects. > 2. For the sake of optimization of the remote protocol, while multiple > calls of begin/commit/rollback are allowed in the remote protocol, > practically, it will mean that we will track the counter locally on the > client and will send begin/commit/rollback only once for the TX lifecycle. > > This model should be uniform across all deployment types. > What are your thoughts on this approach? > > ----- > Andrii Lomakin > YouTrackDB development lead > -- Andrii Lomakin YouTrackDB development lead
