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