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