It sounds like you're proposing a bigger picture change to transactions than just what this particular issue is about. Just to be clear, Dylan and I were trying to come to conclusion on a specific problem with Transactions within our existing model. For that, I'm not sure I see a way outside of ThreadLocal for that issue. If i'm wrong in understanding your proposal perhaps you need to add more details.
More generally speaking, in terms of the bigger picture, ThreadLocal has a convenience for transactions but also is a genuine pain for a lot of applications (server applications). Perhaps you could expand your thoughts a bit as you might bring a new perspective on how to do this stuff. Of course, i would imagine it pretty hard to change our flow on that at this point, but I suppose it doesn't hurt to talk about it. On Fri, Oct 9, 2015 at 5:58 PM, Matt Frantz <[email protected]> wrote: > Sometimes, use of thread-local storage is a code smell. It's a "global" > variable from the standpoint of the thread. Assuming in this case that the > Transaction object itself is not the appropriate place for this state, then > is there something like a TransactionFactory abstraction that could > encapsulate the context that is being stored in ThreadLocal, and then > provided explicitly to the txn? > > On Fri, Oct 9, 2015 at 10:54 AM, Stephen Mallette <[email protected]> > wrote: > > > Graphs that support transactions in TinkerPop (going back to Blueprints) > > have always implemented as ThreadLocal, meaning the transaction is bound > to > > the thread it is executed in. Some graphs, those that can support it, > can > > break out of that model with a "threaded transaction": > > > > > > > http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_threaded_transactions > > > > In this case multiple threads can operate on the same transaction. > > > > > > > > On Fri, Oct 9, 2015 at 1:43 PM, Matt Frantz <[email protected]> > > wrote: > > > > > This is the first time I've noticed a reference to ThreadLocal in a TP > > > discussion, so if you could share a bit of background, I'd appreciate > it. > > > > > > What is the concurrency model for TP from the client standpoint? When > > you > > > say "thread local", do you mean the client thread? Does this behavior > > port > > > across other client libraries, especially threadless environments like > > > JavaScript? > > > > > > I understand API's that affect transactions, but not ones that affect > > > threads. Can't this be a Transaction API? > > > > > > On Fri, Oct 9, 2015 at 7:32 AM, Stephen Mallette <[email protected] > > > > > wrote: > > > > > > > Not sure why, but from the beginning I'd thought of this settings as > > > being > > > > global to the Graph instance, but framed in this context, it doesn't > > seem > > > > right (in any context). I agree with Dylan that this setting should > be > > > > ThreadLocal. > > > > > > > > On Fri, Oct 9, 2015 at 8:58 AM, Dylan Millikin < > > [email protected] > > > > > > > > wrote: > > > > > > > > > Hey guys, > > > > > > > > > > It's become apparent from the discussion in the following issue > that > > > > there > > > > > are some limitations with making the transactional > > READ_WRITE_BEHAVIOR > > > > > global to all graph operations ( > > > > > https://issues.apache.org/jira/browse/TINKERPOP3-875 ) > > > > > > > > > > With gremlin-server as an example this implies that: > > > > > If you issue > > > > graph.tx().onReadWrite(Transaction.READ_WRITE_BEHAVIOR.MANUAL) > > > > > (as is automatic when you use the sessionOpProcessor) every > > subsequent > > > > > request will need to handle transactions manually. I think this > also > > > > > includes other clients that have no idea this operation was > > performed. > > > > > > > > > > The side effect of this is that sessionless requests > > > > (StandardOpProcessor) > > > > > that should be automatically committed, break. > > > > > > > > > > Seeing as fixing this would be a breaking change, let's discuss > pros > > > and > > > > > cons and depending on how things go, create another JIRA ticket > (the > > > one > > > > > linked earlier is being used for another issue) > > > > > > > > > > Best, > > > > > Dylan > > > > > > > > > > > > > > >
