Andrii, I'd like to just quickly clarify Ken's point stating " Sessions won't exist moving forward (4.x+) ". He's saying what you said: " 'session' and 'tx' are essentially the same concepts". We acknowledged that and decided to stop using "session" terminology and instead use "transaction" terminology only to avoid confusion.
Much of what you wrote is in the spirit of what has been considered for 4.x, so that is nice alignment. I do think the goal though is to have a consistent transaction API/system that works for both embedded and remote cases. It will be interesting to see how that is achieved. On Tue, Dec 2, 2025 at 3:53 PM Ken Hu <[email protected]> wrote: > Hi Andrii, > > Good day to you as well. I have a couple questions about this that I would > like some more details on. > > 1. What OGMs are you referring to here? Regular transactions are > complicated enough by itself, I would only want to introduce nested > transactions if there were well maintained OGMs that would have a > demonstrable benefit from this. > 2. I like some of your ideas about removing Transaction as its own class, > but I'm not sure GraphTraversalSource is where it should be instead. Do you > have some more details about what you think the Transaction API should look > like? > 3. Could you expand a bit more on "Transaction scope is limited to the > current thread only". I always get confused by TinkerPop's threaded vs > multithreaded transaction. I find it limiting that an attempt to open > multiple transactions from the same thread ends up returning the same > Transaction instance. Maybe I didn't quite understand what you meant by > this. > 4. Sessions won't exist moving forward (4.x+) as they are tied to remote > Groovy execution. So let's continue this conversation as simply > transactions and not refer to sessions at all to prevent confusion, unless > you intend to have these changes in the 3.8.x line? > > Regards, > Ken > > > On Tue, Dec 2, 2025 at 3:33 AM Andrii Lomakin via dev < > [email protected]> wrote: > > > 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 > > >
