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