Hey guys I thought I would give my 5 cents. Keep in mind this is coming from a non-java background and working with the stack through gremlin-server.
On my end of the ecosystem (web), there aren't that many situations where nested transactions are necessary over single transactions. As a testament to this, many frameworks will provide functionality for "nesting" transactions with various DBs but under the hood they're simply managing a single transaction. The reason behind that behavior is because it's simply easier and more logical to set up whichever transactions you need on a small unit of code without worrying about whether or not that transaction is going to be called within the context of another transaction (it may or it may not). The nesting in that case simply isn't necessary. I will however provide a counter-example that we've probably seen a lot. When writing a large number of elements at a time it is necessary to .commit() incrementally to work around memory issues. Although that is tolerable in a prototyping and testing environment, it isn't so much in production. Nested transactions would definitely help in this case but I don't know that there would often be user cases that would justify the headache of implementing it. (Maybe duplicating/moving large sections of a graph?) On Tue, Apr 7, 2015 at 7:40 PM, Matt Frantz <[email protected]> wrote: > OK, I see how it makes sense to throw an exception. > > On Tue, Apr 7, 2015 at 10:09 AM, Stephen Mallette <[email protected]> > wrote: > > > My reason for not being idempotent was due to a point Matthias touched > on, > > in that users have generally misunderstood threaded transactions and i'd > > worry that they'd expect a nested transaction. > > > > On Tue, Apr 7, 2015 at 12:40 PM, Matthias Broecheler <[email protected]> > > wrote: > > > > > One could argue that this should open a nested transaction which is > > > supported by some RDBMS. I am NOT in favor of nested transactions due > to > > > their poorly understood semantics and usability issues. Also, I don't > > think > > > we want to open that can of worms before the GA release. However, to > keep > > > that door open you might want to throw an exception here for now. > > > > > > On Tue, Apr 7, 2015 at 8:53 AM Matt Frantz <[email protected] > > > > > wrote: > > > > > > > What about making this idempotent? > > > > > > > > On Tue, Apr 7, 2015 at 7:56 AM, Stephen Mallette < > [email protected] > > > > > > > wrote: > > > > > > > > > I'd like to enforce some behavior on those Graph implementations > that > > > > will > > > > > support "threaded transactions". Recall that a threaded > transaction > > is > > > > one > > > > > where multiple threads can interact with the same transactional > > > context. > > > > > In TP3 you can create one with: > > > > > > > > > > tg = g.tx().create() > > > > > > > > > > which returns a Graph instance that is ready for multiple threads > to > > > > > operate on it. But what does the following line mean where we try > to > > > > > create a threaded transaction from a graph enabled with a threaded > > > > > transaction? > > > > > > > > > > tg.tx().create() > > > > > > > > > > Should that be allowed and if so, what would that mean? In my > mind, > > i > > > > > think we shouldn't allow it. I think the behavior should be to just > > > throw > > > > > an exception and the supportsThreadedTransaction feature method > > should > > > > > return false. I'd like to write tests to enforce that case so that > > we > > > > > achieve consistency across implementations. > > > > > > > > > > Does anyone has thoughts on another way that this should work? or > > does > > > > this > > > > > approach just make sense? > > > > > > > > > > Thanks, > > > > > > > > > > Stephen > > > > > > > > > > > > > > >
