[DISCUSS] Tie Rebindings to Transaction Manager in Gremlin Server

[Stephen Mallette <sp...@gmail.com>]

The current "tranaction manager" in Gremlin Server is just like Rexster's
and it's not very smart.  It makes no distinction about what graphs were
actually affected when it issues its auto-commits/rollbacks at the end of a
sessionless request.  For those with a number of different Graph instances
configured in Gremlin Server, that's a lot of extra empty commits if the
intent is to just mutate a single graph in the set.  I'm not sure what that
time amounts to, but it seems sensible that if we could only commit when
needed then it would be better than lots of extra commits for nothing.

As it so happens we have the rebindings feature (wonder why didn't call
that "alias") in Gremlin Server:

http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding

So we could use that to tell the transaction manager which graph the user
is working with and thus allow the correct commit on the right graph.  If
no rebindings are supplied, I guess we could stick with the current model.

It is a potentially breaking change to people already using rebindings only
in the sense that if they have two graphs in Gremlin Server, then chose to
use a rebind for one, but then issued scripts that directly referenced the
other, obviously, under this new model, the transaction would be
uncommitted on the direct reference - they would have to alter the code to
rebind both.

Generally speaking, I think we want to encourage rebinding as a pattern as
it makes code more flexible as your scripts don't get bound to the name of
the graph in Gremlin Server - they can be bound to a more general alias.
So this change would perhaps lead folks in this direction.

Anyone against using rebindings in that fashion?

Re: [DISCUSS] Tie Rebindings to Transaction Manager in Gremlin Server

[Stephen Mallette <sp...@gmail.com>]

My survey didn't get very far.  One response in who uses multiple graphs in
single requests.  I'd expected more, but perhaps that feature isn't really
being used.  I think that having some kind of "mode" as Matt suggested
would be good.  Anyway - i've written up the ticket as such:

https://issues.apache.org/jira/browse/TINKERPOP3-930

and the "old way" can be preserved - for now.

On Tue, Oct 20, 2015 at 8:38 AM, Stephen Mallette <sp...@gmail.com>
wrote:

> Started this "survey" on gremlin-users to get a sense of what folks were
> doing:
>
> https://groups.google.com/forum/#!topic/gremlin-users/6l9-z5g7FYI
>
> On Fri, Oct 16, 2015 at 3:25 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
>> I didn't want to go to "one-and-only" talk, but I was going to go there
>> assuming folks were accepting of this proposal.  I'd likely want to take
>> that discussion to gremlin-users as well.  I'm wondering how many folks
>> unsafely do a multi-graph transaction in a single request.
>>
>> On Fri, Oct 16, 2015 at 11:04 AM, Matt Frantz <matthew.h.frantz@gmail.com
>> > wrote:
>>
>>> It would seem that we want a sort of "strict" mode where the client must
>>> declare the (one-and-only?) graph that they want to use.  That way, we
>>> could deprecate support for the server-side graph names, and raise an
>>> exception if strict mode is enabled.  It becomes sort of an "import"
>>> feature from the client standpoint, i.e. they must import a graph to use
>>> it.
>>>
>>> On Thu, Oct 15, 2015 at 12:32 PM, Stephen Mallette <spmallette@gmail.com
>>> >
>>> wrote:
>>>
>>> > The current "tranaction manager" in Gremlin Server is just like
>>> Rexster's
>>> > and it's not very smart.  It makes no distinction about what graphs
>>> were
>>> > actually affected when it issues its auto-commits/rollbacks at the end
>>> of a
>>> > sessionless request.  For those with a number of different Graph
>>> instances
>>> > configured in Gremlin Server, that's a lot of extra empty commits if
>>> the
>>> > intent is to just mutate a single graph in the set.  I'm not sure what
>>> that
>>> > time amounts to, but it seems sensible that if we could only commit
>>> when
>>> > needed then it would be better than lots of extra commits for nothing.
>>> >
>>> > As it so happens we have the rebindings feature (wonder why didn't call
>>> > that "alias") in Gremlin Server:
>>> >
>>> >
>>> http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding
>>> >
>>> > So we could use that to tell the transaction manager which graph the
>>> user
>>> > is working with and thus allow the correct commit on the right graph.
>>> If
>>> > no rebindings are supplied, I guess we could stick with the current
>>> model.
>>> >
>>> > It is a potentially breaking change to people already using rebindings
>>> only
>>> > in the sense that if they have two graphs in Gremlin Server, then
>>> chose to
>>> > use a rebind for one, but then issued scripts that directly referenced
>>> the
>>> > other, obviously, under this new model, the transaction would be
>>> > uncommitted on the direct reference - they would have to alter the
>>> code to
>>> > rebind both.
>>> >
>>> > Generally speaking, I think we want to encourage rebinding as a
>>> pattern as
>>> > it makes code more flexible as your scripts don't get bound to the
>>> name of
>>> > the graph in Gremlin Server - they can be bound to a more general
>>> alias.
>>> > So this change would perhaps lead folks in this direction.
>>> >
>>> > Anyone against using rebindings in that fashion?
>>> >
>>>
>>
>>
>

Re: [DISCUSS] Tie Rebindings to Transaction Manager in Gremlin Server

[Stephen Mallette <sp...@gmail.com>]

Started this "survey" on gremlin-users to get a sense of what folks were
doing:

https://groups.google.com/forum/#!topic/gremlin-users/6l9-z5g7FYI

On Fri, Oct 16, 2015 at 3:25 PM, Stephen Mallette <sp...@gmail.com>
wrote:

> I didn't want to go to "one-and-only" talk, but I was going to go there
> assuming folks were accepting of this proposal.  I'd likely want to take
> that discussion to gremlin-users as well.  I'm wondering how many folks
> unsafely do a multi-graph transaction in a single request.
>
> On Fri, Oct 16, 2015 at 11:04 AM, Matt Frantz <ma...@gmail.com>
> wrote:
>
>> It would seem that we want a sort of "strict" mode where the client must
>> declare the (one-and-only?) graph that they want to use.  That way, we
>> could deprecate support for the server-side graph names, and raise an
>> exception if strict mode is enabled.  It becomes sort of an "import"
>> feature from the client standpoint, i.e. they must import a graph to use
>> it.
>>
>> On Thu, Oct 15, 2015 at 12:32 PM, Stephen Mallette <sp...@gmail.com>
>> wrote:
>>
>> > The current "tranaction manager" in Gremlin Server is just like
>> Rexster's
>> > and it's not very smart.  It makes no distinction about what graphs were
>> > actually affected when it issues its auto-commits/rollbacks at the end
>> of a
>> > sessionless request.  For those with a number of different Graph
>> instances
>> > configured in Gremlin Server, that's a lot of extra empty commits if the
>> > intent is to just mutate a single graph in the set.  I'm not sure what
>> that
>> > time amounts to, but it seems sensible that if we could only commit when
>> > needed then it would be better than lots of extra commits for nothing.
>> >
>> > As it so happens we have the rebindings feature (wonder why didn't call
>> > that "alias") in Gremlin Server:
>> >
>> > http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding
>> >
>> > So we could use that to tell the transaction manager which graph the
>> user
>> > is working with and thus allow the correct commit on the right graph.
>> If
>> > no rebindings are supplied, I guess we could stick with the current
>> model.
>> >
>> > It is a potentially breaking change to people already using rebindings
>> only
>> > in the sense that if they have two graphs in Gremlin Server, then chose
>> to
>> > use a rebind for one, but then issued scripts that directly referenced
>> the
>> > other, obviously, under this new model, the transaction would be
>> > uncommitted on the direct reference - they would have to alter the code
>> to
>> > rebind both.
>> >
>> > Generally speaking, I think we want to encourage rebinding as a pattern
>> as
>> > it makes code more flexible as your scripts don't get bound to the name
>> of
>> > the graph in Gremlin Server - they can be bound to a more general alias.
>> > So this change would perhaps lead folks in this direction.
>> >
>> > Anyone against using rebindings in that fashion?
>> >
>>
>
>

Re: [DISCUSS] Tie Rebindings to Transaction Manager in Gremlin Server

[Stephen Mallette <sp...@gmail.com>]

I didn't want to go to "one-and-only" talk, but I was going to go there
assuming folks were accepting of this proposal.  I'd likely want to take
that discussion to gremlin-users as well.  I'm wondering how many folks
unsafely do a multi-graph transaction in a single request.

On Fri, Oct 16, 2015 at 11:04 AM, Matt Frantz <ma...@gmail.com>
wrote:

> It would seem that we want a sort of "strict" mode where the client must
> declare the (one-and-only?) graph that they want to use.  That way, we
> could deprecate support for the server-side graph names, and raise an
> exception if strict mode is enabled.  It becomes sort of an "import"
> feature from the client standpoint, i.e. they must import a graph to use
> it.
>
> On Thu, Oct 15, 2015 at 12:32 PM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > The current "tranaction manager" in Gremlin Server is just like Rexster's
> > and it's not very smart.  It makes no distinction about what graphs were
> > actually affected when it issues its auto-commits/rollbacks at the end
> of a
> > sessionless request.  For those with a number of different Graph
> instances
> > configured in Gremlin Server, that's a lot of extra empty commits if the
> > intent is to just mutate a single graph in the set.  I'm not sure what
> that
> > time amounts to, but it seems sensible that if we could only commit when
> > needed then it would be better than lots of extra commits for nothing.
> >
> > As it so happens we have the rebindings feature (wonder why didn't call
> > that "alias") in Gremlin Server:
> >
> > http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding
> >
> > So we could use that to tell the transaction manager which graph the user
> > is working with and thus allow the correct commit on the right graph.  If
> > no rebindings are supplied, I guess we could stick with the current
> model.
> >
> > It is a potentially breaking change to people already using rebindings
> only
> > in the sense that if they have two graphs in Gremlin Server, then chose
> to
> > use a rebind for one, but then issued scripts that directly referenced
> the
> > other, obviously, under this new model, the transaction would be
> > uncommitted on the direct reference - they would have to alter the code
> to
> > rebind both.
> >
> > Generally speaking, I think we want to encourage rebinding as a pattern
> as
> > it makes code more flexible as your scripts don't get bound to the name
> of
> > the graph in Gremlin Server - they can be bound to a more general alias.
> > So this change would perhaps lead folks in this direction.
> >
> > Anyone against using rebindings in that fashion?
> >
>

Re: [DISCUSS] Tie Rebindings to Transaction Manager in Gremlin Server

[Matt Frantz <ma...@gmail.com>]

It would seem that we want a sort of "strict" mode where the client must
declare the (one-and-only?) graph that they want to use.  That way, we
could deprecate support for the server-side graph names, and raise an
exception if strict mode is enabled.  It becomes sort of an "import"
feature from the client standpoint, i.e. they must import a graph to use it.

On Thu, Oct 15, 2015 at 12:32 PM, Stephen Mallette <sp...@gmail.com>
wrote:

> The current "tranaction manager" in Gremlin Server is just like Rexster's
> and it's not very smart.  It makes no distinction about what graphs were
> actually affected when it issues its auto-commits/rollbacks at the end of a
> sessionless request.  For those with a number of different Graph instances
> configured in Gremlin Server, that's a lot of extra empty commits if the
> intent is to just mutate a single graph in the set.  I'm not sure what that
> time amounts to, but it seems sensible that if we could only commit when
> needed then it would be better than lots of extra commits for nothing.
>
> As it so happens we have the rebindings feature (wonder why didn't call
> that "alias") in Gremlin Server:
>
> http://tinkerpop.incubator.apache.org/docs/3.0.1-incubating/#_rebinding
>
> So we could use that to tell the transaction manager which graph the user
> is working with and thus allow the correct commit on the right graph.  If
> no rebindings are supplied, I guess we could stick with the current model.
>
> It is a potentially breaking change to people already using rebindings only
> in the sense that if they have two graphs in Gremlin Server, then chose to
> use a rebind for one, but then issued scripts that directly referenced the
> other, obviously, under this new model, the transaction would be
> uncommitted on the direct reference - they would have to alter the code to
> rebind both.
>
> Generally speaking, I think we want to encourage rebinding as a pattern as
> it makes code more flexible as your scripts don't get bound to the name of
> the graph in Gremlin Server - they can be bound to a more general alias.
> So this change would perhaps lead folks in this direction.
>
> Anyone against using rebindings in that fashion?
>