Given that this is a major version upgrade, I think we can break the core interfaces as much as needed as long as there is a good reason for doing so. I understand the hesitancy to make breaking changes, but it's become apparent that the APIs don't work well for the remote case. I also expect that the 3.x line will be maintained for a while even after the release of TinkerPop 4 so that will give users extra time to upgrade. But yes, we should keep the upgrade path in mind.
On Fri, Jan 23, 2026 at 11:49 PM pieter <[email protected]> wrote: > Hi, > > Before discussing these changes further, I need some clarity on how > much we are willing to break core interfaces in TP 4? > > The core interfaces have been around for more than a decade. i.e. > millions and millions of lines of code in production. > > Personally I am in the 'don't break user space'. camp. > > If we do make drastic changes, we should right from the start think > about the upgrade path and think about the impact on existing code > bases. > > Regards > Pieter > > > > > On Wed, 2026-01-21 at 20:40 -0800, Ken Hu wrote: > > I agree that record consistency is important, but I feel that where > > this > > gets solved depends on how users integrate graph databases into their > > applications. There are probably frameworks and OGM/ORMs that can do > > this > > detaching/unloading that you are mentioning as a solution. If a user > > directly integrates the database as an external service using a > > driver, > > then having it as part of the API could be useful. I need to think > > about > > this more. > > > > To your second point about platform-independence, I think this has > > always > > been a goal of TinkerPop that has never quite been realized. Even > > today, > > there are some examples of Gremlin that return results that are > > provider-dependent and so there are specific cases where it isn't > > truly > > portable. I agree that a difference in read consistency amongst > > vendors/providers means those using transactions can't move between > > different databases unless they find another database with the exact > > same > > transaction behavior. But I'm not entirely sure we can get all > > providers to > > match the same behavior in this case. > > > > On Tue, Jan 20, 2026 at 11:26 PM Andrii Lomakin via dev < > > [email protected]> wrote: > > > > > Hi Ken. > > > Thank you for sharing this with us. > > > > > > After some thought, I agree that we need explicit TX management > > > methods. > > > From my perspective, what I wrote is only the tip of the iceberg, > > > as such > > > questions as consistency of the queries and validity of the data > > > contained > > > in vertices directly bound to the concept of TX lifecycle. > > > > > > Example (it can be applied to any database, not just a graph > > > database, so I > > > will use the general record concept). > > > > > > I have created record A { id: 1, value: "val1"} , committed it, and > > > passed > > > it to another thread. > > > After that, another method updated the same record B {id: 1, value > > > : > > > "val2"} and committed it. > > > > > > A and B in this context object identity, not DB record identity. > > > > > > But I have the record A in another thread with potentially stale > > > data. > > > What then should another thread read when it accesses `A.value`? > > > > > > I doubt it should read stale data. In our database, records are > > > automatically switched to the unloaded state after commit and can > > > be read > > > in a new thread only when a new transaction is started. > > > The question of record consistency, from my point of view, is an > > > important > > > one and cannot be overlooked, as it influences how users interact > > > with the > > > TP API and to what degree it is really platform-independent. > > > > > > > > > On Wed, Jan 21, 2026 at 7:58 AM Ken Hu <[email protected]> wrote: > > > > > > > Here are some of my current thoughts on the proposed changes and > > > > discussion. > > > > > > > > -deprecate open() and replace with begin() > > > > -I agree with this as having both is confusing and unncessary > > > > > > > > -Transaction class is deprecated, and TX control functionality is > > > delegated > > > > to the GraphTraversal/Graph instances > > > > -I mostly agree with this as well, but I think it's probably > > > > better > > > if > > > > it was delegated to GraphTraversalSource. > > > > > > > > -tx() method is deprecated. > > > > -I think this makes sense as I always found how tx() works > > > > with > > > remote > > > > to be unintuitive. > > > > > > > > -Transaction scope is limited to the current thread only > > > > -I had some questions about this earlier, but having thought > > > > about it > > > > after seeing Andrii's architectural diagram, it's probably fine > > > > since > > > most > > > > developers (in all languages TinkerPop supports) will be used to > > > > this > > > being > > > > how it works as long as we have something that represents what a > > > connection > > > > is in other databases. > > > > > > > > -I believe Non-TX mode is not appropriate for handling graph data > > > > structures. > > > > -Further, I'd say that transactions should be optional. Many > > > > persistent > > > > db/graph systems are eventually consistent and do not support > > > transactions, > > > > so they should not be burdened with concepts foreign to them. > > > > -I tend to agree with Pieter here. My reasoning is different > > > > though, > > > > one of the use cases for graphs is analytics and transactions > > > > aren't > > > really > > > > used in that case. > > > > > > > > -I think we DO need methods for explicit transaction management, > > > > but 90% > > > of > > > > the cases will be covered by implicit transaction management > > > > throughout > > > the > > > > GraphTraversal life cycle. > > > > -What I propose is to use lambda-controlled TXs > > > > -My idea is that the transaction api should be unopinionated. > > > > That means > > > it > > > > should follow closely to `UserTransaction` > > > > -I think having implicit transactions is fine as long as it's > > > > just an > > > > option. I'm not sure which should be the default. I'm not sure we > > > > can > > > make > > > > lambda-controlled transactions work though since lambdas wouldn't > > > > be > > > > compatible with Gremlin scripts. At this point, we probably still > > > > want > > > > parity between scripts and GraphTraversals. > > > > > > > > I think we need some more proposals for what the explicit > > > > transaction > > > > management API could look like because we probably can't move > > > > ahead with > > > > lambda-controlled TX for now and the current tx() solution is > > > > clunky. > > > I'll > > > > try to propose one in the next couple of days. > > > > > > > > On Wed, Jan 7, 2026 at 12:24 PM pieter <[email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I had a brief discussion with Andrii in the discord chat > > > > > regarding the > > > > > transaction api. > > > > > > > > > > My idea is that the transaction api should be unopinionated. > > > > > That means it should follow closely to > > > > > `javax.transaction.UserTransaction` which in turn means we have > > > > > a > > > > > dedicated class modelling the transaction with `begin()`, > > > > > `commit()` > > > > > and `rollback()`. > > > > > > > > > > My reasoning is that gremlin is a low level graph language. > > > > > There are > > > > > many ways different developers / architects can go about > > > > > integrating > > > > > gremlin into their stack. > > > > > > > > > > Some like lambdas, some like IOT containers, some have domain > > > > > entity > > > > > frameworks, some use aspect orienated programming and on an on. > > > > > > > > > > It is common for IOT containers to manage transaction > > > > > boundaries and > > > > > lifecycles. Similarly it is common to use the web server's > > > > > interceptors > > > > > to manage transaction boundaries. And it is very common to do > > > > > it all > > > > > manually... > > > > > > > > > > Further, I'd say that transactions should be optional. Many > > > > > persistent > > > > > db/graph systems are eventually consistent and do not support > > > > > transactions, so they should not be burdened with concepts > > > > > foreign to > > > > > them. > > > > > > > > > > Regarding binding the transaction to the thread: > > > > > This is the only way I have ever worked so its entirely natural > > > > > to me. > > > > > However I can image that people want to defince their own > > > > > transaction > > > > > context, so perhaps we should not hardcode that part. Long ago > > > > > Gavin > > > > > King from Hibernate fame had the notion of `conversation` > > > > > context. > > > > > Perhaps such things are still around? > > > > > > > > > > Regards > > > > > Pieter > > > > > > > > > > On Thu, 2025-12-11 at 09:02 +0100, Andrii Lomakin via dev > > > > > wrote: > > > > > > Unfortunately, all images have been removed, so I am sending > > > > > > a link > > > > > > to the diagrams instead > > > > > > > https://miro.com/app/board/uXjVGdd8m44=/?share_link_id=686668490384 > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Dec 11, 2025 at 8:53 AM Andrii Lomakin > > > > > > <[email protected]> wrote: > > > > > > > Good day. > > > > > > > > > > > > > > If I followed Ken's line of thought correctly, I would like > > > > > > > to > > > > > > > expand it to be part of the new proposal for the > > > > > > > transaction API. > > > > > > > First of all, about the model, I think we came to a > > > > > > > consensus that > > > > > > > it should be: > > > > > > > > > > > > > > > > > > > > > image.png > > > > > > > The point is that we do not have a notion of connection in > > > > > > > TinkerPop, but we have a notion of GraphTraversal. > > > > > > > So, from my perspective, this diagram can be changed to > > > > > > > image.png > > > > > > > > > > > > > > There is a corner case for Non-TX databases that we need to > > > > > > > discuss. > > > > > > > I believe Non-TX mode is not appropriate for handling graph > > > > > > > data > > > > > > > structures. GQL, for example, requires serializable > > > > > > > isolation to > > > > > > > satisfy the standard requirements. > > > > > > > Instead, we should require to have presence of a > > > > > > > transaction, which > > > > > > > is started implicitly when GraphTraversal is created and > > > > > > > committed > > > > > > > once it is closed. > > > > > > > > > > > > > > I think we DO need methods for explicit transaction > > > > > > > management, but > > > > > > > 90% of the cases will be covered by implicit transaction > > > > > > > management > > > > > > > throughout the GraphTraversal life cycle. > > > > > > > 1. TX is started when GraphTraversal is created. > > > > > > > 2. TX is committed when GraphTraversal is closed (which > > > > > > > includes > > > > > > > terminal operations like toList or iterate). > > > > > > > 3. TX is rolled back in case of exceptional execution of > > > > > > > GraphTraversal. Users can always roll back a transaction by > > > > > > > using > > > > > > > the fail() step. > > > > > > > > > > > > > > We also provide in the YTDB the following methods that I > > > > > > > hope will > > > > > > > become part of the framework: gSource.computeInTx(g ->{}), > > > > > > > gSource.executeInTx(g - {}), gSource.autoExecuteInTx(g - > > > > > > > {}: g) > > > > > > > (this one executes g.iterate() on the returned > > > > > > > GraphTraversal, > > > > > > > which we find really handy). > > > > > > > > > > > > > > Now, regarding explicit TX management. > > > > > > > I think that explicit TX management is still needed if you > > > > > > > want to > > > > > > > execute several queries and mix them with complex logic, > > > > > > > but I > > > > > > > think that methods that explicitly cause TX > > > > > > > begin/start/commit are > > > > > > > confusing and provide bad DevX. > > > > > > > What I propose is to use lambda-controlled TXs (slightly > > > > > > > different > > > > > > > from the above). I think that an explicit rollback/commit > > > > > > > of TX by > > > > > > > the user is similar to the goto operator in old programming > > > > > > > languages; it gives finer control over TXs, but overall > > > > > > > only adds > > > > > > > confusion and can be completely avoided in modern > > > > > > > languages. > > > > > > > > > > > > > > Explicit control on TXs is proposed to be implemented using > > > > > > > methods > > > > > > > similar to above, with a different signature, namely: > > > > > > > gSource.executeInTx(graphTraversalSupplier -> { > > > > > > > var g = graphTraversalSupplier.get(); > > > > > > > var v = g.V().next(); > > > > > > > g.close() > > > > > > > > > > > > > > v.property("p", "val"); > > > > > > > int i = v.value("int"); > > > > > > > > > > > > > > if(i > 0) { > > > > > > > g = graphTraversalSupplier.get(); > > > > > > > g.V().has("i2", i).property("i2", i + > > > > > > > 1).iterate(); > > > > > > > } > > > > > > > }) > > > > > > > > > > > > > > In this case, the transaction is detached from > > > > > > > GraphTraversal, and > > > > > > > its lifecycle is not controlled by GraphTraversal. > > > > > > > Instead, TX is committed if an exception is not thrown from > > > > > > > the > > > > > > > lambda method. > > > > > > > > > > > > > > To inform the user if GraphTraversal controls TX or not, a > > > > > > > simple > > > > > > > isTxAttached method is proposed to be introduced > > > > > > > gSource.<V>computeInTX(graphTraversalSupplier -> {}) works > > > > > > > in > > > > > > > similar way but returns value. > > > > > > > > > > > > > > > > > > > > > So the final diagram could look like the following: > > > > > > > > > > > > > > > > > > > > > image.png > > > > > > > > > > > > > > Please note that in this model, there is no need for an > > > > > > > explicit > > > > > > > transaction object. > > > > > > > > > > > > > > On Fri, Dec 5, 2025 at 10:18 AM Andrii Lomakin > > > > > > > <[email protected]> wrote: > > > > > > > > Good day, Ken. > > > > > > > > > > > > > > > > > This could map to multiple threads on the provider > > > > > > > > > side. It's > > > > > > > > probably OK if something like "g.tx()..." returns the > > > > > > > > same > > > > > > > > transaction. We could require users to open multiple > > > > > > > > DriverRemoteConnections/Clients to achieve this and that > > > > > > > > would be > > > > > > > > similar to other data connectivity APIs. > > > > > > > > > > > > > > > > Unfortunately I do not follow, could you elaborate more > > > > > > > > or give > > > > > > > > me example how do you see it ? > > > > > > > > > > > > > > > > On Thu, Dec 4, 2025 at 7:06 PM Ken Hu > > > > > > > > <[email protected]> > > > wrote: > > > > > > > > > I might be thinking about this too much for just the > > > > > > > > > remote > > > > > > > > > case and not considering the embedded case enough. In > > > > > > > > > my mind, > > > > > > > > > there just needs to be an easy way for users of the > > > > > > > > > language > > > > > > > > > variants (in particular JavaScript because of its > > > > > > > > > single > > > > > > > > > threaded nature) to start multiple transactions from a > > > > > > > > > single > > > > > > > > > thread. This could map to multiple threads on the > > > > > > > > > provider > > > > > > > > > side. It's probably OK if something like "g.tx()..." > > > > > > > > > returns > > > > > > > > > the same transaction. We could require users to open > > > > > > > > > multiple > > > > > > > > > DriverRemoteConnections/Clients to achieve this and > > > > > > > > > that would > > > > > > > > > be similar to other data connectivity APIs. > > > > > > > > > > > > > > > > > > On Thu, Dec 4, 2025 at 2:37 AM Andrii Lomakin via dev > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > The point about having multiple concurrent > > > > > > > > > > transactions > > > > > > > > > > within the same > > > > > > > > > > thread warrants a more detailed discussion. > > > > > > > > > > > > > > > > > > > > To compare this behavior, consider how major SQL > > > > > > > > > > databases > > > > > > > > > > handle attempts > > > > > > > > > > to start a second transaction when one is already > > > > > > > > > > active: > > > > > > > > > > > > > > > > > > > > 1. Error out: The database prevents the operation, > > > > > > > > > > signaling > > > > > > > > > > that a > > > > > > > > > > transaction is already active (e.g., "Transaction > > > > > > > > > > already > > > > > > > > > > active"). > > > > > > > > > > 2. Create a nested transaction (savepoint): The > > > > > > > > > > database > > > > > > > > > > creates a > > > > > > > > > > sub-scope of the first transaction, not an > > > > > > > > > > independent > > > > > > > > > > transaction. If the > > > > > > > > > > parent transaction fails, the child scope also fails. > > > > > > > > > > 3. Implicitly commit the first: The database > > > > > > > > > > automatically > > > > > > > > > > commits the > > > > > > > > > > first transaction to open the second one (a common > > > > > > > > > > behavior > > > > > > > > > > in MySQL DDL). > > > > > > > > > > > > > > > > > > > > As far as I know, only Firebird has historically > > > > > > > > > > allowed > > > > > > > > > > several truly > > > > > > > > > > independent transactions concurrently on the same > > > > > > > > > > thread. I > > > > > > > > > > suspect support > > > > > > > > > > for simultaneous transactions may be even more > > > > > > > > > > limited among > > > > > > > > > > graph database > > > > > > > > > > vendors. > > > > > > > > > > > > > > > > > > > > On Thu, Dec 4, 2025 at 10:47 AM Andrii Lomakin > > > > > > > > > > <[email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Good day. > > > > > > > > > > > As for questions from Ken > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > We have such an OGM using TinkerPop that is well > > > > > > > > > > maintained, if you mean > > > > > > > > > > > by this years of support and thousands of instances > > > > > > > > > > > running > > > > > > > > > > on OS version. > > > > > > > > > > > However, I have given it thought and believe that > > > > > > > > > > > it is a > > > > > > > > > > relatively rare > > > > > > > > > > > case, and OGM is so complex that it can manage > > > > > > > > > > > nested > > > > > > > > > > transactions itself > > > > > > > > > > > if needed. > > > > > > > > > > > I think we can support nested transactions on pause > > > > > > > > > > > for > > > > > > > > > > now, till we > > > > > > > > > > > receive more feedback from users. > > > > > > > > > > > > > > > > > > > > > > There are many inconsistencies to discuss in the TX > > > > > > > > > > lifecycle, even > > > > > > > > > > > without nested transactions. > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > Yeah, we already removed Groovy support in our > > > > > > > > > > > fork, so it > > > > > > > > > > is even now in > > > > > > > > > > > our distribution TX, and the session is the same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you expand a bit more on "Transaction scope > > > > > > > > > > > > is > > > > > > > > > > limited to the > > > > > > > > > > > current thread only". > > > > > > > > > > > I mean that TX visibility and manipulation are > > > > > > > > > > > limited to a > > > > > > > > > > single thread > > > > > > > > > > > where it is created. > > > > > > > > > > > If some of the providers support TX visibility > > > > > > > > > > > between > > > > > > > > > > several threads, > > > > > > > > > > > that will only add a bonus for them if such a need > > > > > > > > > > > arises, > > > > > > > > > > of course, > > > > > > > > > > > without breaking the API. > > > > > > > > > > > > > > > > > > > > > > > I find it limiting that an attempt to open > > > > > > > > > > > > multiple > > > > > > > > > > transactions from > > > > > > > > > > > the same thread ends up returning the same > > > > > > > > > > > Transaction > > > > > > > > > > instance > > > > > > > > > > > Do you propose to support several transactions in > > > > > > > > > > > the same > > > > > > > > > > thread? > > > > > > > > > > > I am afraid not all current vendors can support > > > > > > > > > > > this model. > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 3, 2025 at 1:23 PM Stephen Mallette > > > > > > > > > > <[email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Andrii Lomakin > > > > > > > > > > > YouTrackDB development lead > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Andrii Lomakin > > > YouTrackDB development lead > > > >
