Queries and Transaction Context: Transient modifications

[Martin Häusler <ma...@gmail.com>]

Hi,

I'm currently developing an implementation for the Gremlin 3.x API which
supports full ACID transactions. The problem I am currently facing is the
graph transaction context. Assume that the following happens:

Graph g = ... ; // acquire empty graph
g.addVertex("name", "martin");
g.commit();

Vertex me = g.V().has("name", "martin").toSet().iterator.next();
me.property("name", "john");
// note: no g.commit() here!

Vertex me2 = g.V().has("name", "martin").toSet().iterator.next(); // is
this supposed to work?


The question that arises here is: should the second gremlin query return
the vertex? On the one hand, in the current transaction context, the vertex
data has been changed - on the other hand, it has not been committed yet.
Neither variant is more "correct" than the other, and the API documentation
tells little about these issues. Moreover, TinkerGraph as the reference
implementation does not support transactions. How should this be handled?
Is there some common consensus among gremlin vendors?

Kind regards,
Martin

Re: Queries and Transaction Context: Transient modifications

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

The second Gremlin query should not return anything as you set the name
property "john".  You didn't commit but you are in the same transaction as
that change is occurring on the same thread.  if you had executed:

Vertex me2 = g.V().has("name", "martin").toSet().iterator.next();

on a different thread, and your setting the "name" property to "john" did
not yet commit then you would get a result.

On Wed, Dec 2, 2015 at 8:26 AM, Martin Häusler <ma...@gmail.com>
wrote:

> Hi,
>
> I'm currently developing an implementation for the Gremlin 3.x API which
> supports full ACID transactions. The problem I am currently facing is the
> graph transaction context. Assume that the following happens:
>
> Graph g = ... ; // acquire empty graph
> g.addVertex("name", "martin");
> g.commit();
>
> Vertex me = g.V().has("name", "martin").toSet().iterator.next();
> me.property("name", "john");
> // note: no g.commit() here!
>
> Vertex me2 = g.V().has("name", "martin").toSet().iterator.next(); // is
> this supposed to work?
>
>
> The question that arises here is: should the second gremlin query return
> the vertex? On the one hand, in the current transaction context, the vertex
> data has been changed - on the other hand, it has not been committed yet.
> Neither variant is more "correct" than the other, and the API documentation
> tells little about these issues. Moreover, TinkerGraph as the reference
> implementation does not support transactions. How should this be handled?
> Is there some common consensus among gremlin vendors?
>
> Kind regards,
> Martin
>