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