Small clarification. Implementation notes are related to changes in the remote protocol.
On Tue, Dec 2, 2025 at 8:55 AM Andrii Lomakin <[email protected]> wrote: > 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 > -- Andrii Lomakin YouTrackDB development lead
