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 > > >
