Transaction handling with Remote graph

[shrikant pachauri]

Greetings,

Hi, I was trying out Janus graph with remote and I got some elementary doubt related to the transaction handling. Consider the architecture of the application.

           API Layer ------> Service Layer -------> DAO layer --------> JanusGraph

API Layer: It redirects requests from the endPoint to the intended Service layer method.

Service Layer: Basically this layer constitutes of the Business logic and it may call multiple DAO layer methods to serve the request.

DAO Layer: Contains Dumb methods to interact with Janus graph to facilitate the creation of edge, vertex or like adding a property to them. 

Now Since in remote graph, every traversal is atomically committed( is within a transaction). Suppose I want to maintain the transaction on the service layer like if there comes any exception in a request the graph must remain unchanged( all the transaction must be rolled back). 

Can anyone explain or suggest some design to implement the same??

Regards,

Shrikant

[Florian Hockmann]

Hi Shrikant,

if you really want to implement the architecture like that and maintain transactions across different requests to Gremlin Server, then you basically have to implement transaction handling yourself in your application. This means that you have to keep track of which operations where executed in a transaction successfully so you can roll them back in case an exception occurs.

I wonder however whether you couldn't use a simpler approach. Using a layered architecture introduces a tight coupling between these layers as most features need to be implemented in most of these layers. So, I would consider an architecture without splitting everything in layers in general, irrespective of JanusGraph.

Needing to maintain a transaction in a high layer like the service layer in your case that spans over multiple calls to another layer which in turn sends queries to JanusGraph also introduces a lot of complexity. Any reason why you can't just create one method per use case in your service that handles all modifications in JanusGraph itself and ideally in a single Gremlin traversal? So, one traversal per atomic modification, whatever an atomic modification is in your case (like a customer with the bought product). That way, the transaction handling of Gremlin Server already ensures that your modifications are either completely persisted or not at all.

[vasil...@gmail.com]

Hi Florian,

We also observe that if we run remote mode then yes, each remote call results in auto-commit for each call, meaning:

           API Layer --- 1 local call ---> Service Layer --- X local calls ----> DAO layer ---X remote calls -----> JanusGraph ---X remote calls ---> Nosql

But if we embed janusgraph into service and use it as a library, then transactions seems to be working fine:  

           API Layer --- 1 local call ---> Service Layer --- X local calls ----> DAO layer ---X local calls -----> JanusGraph ---X remote calls ---> Nosql

We just started evaluation of janusgraph and I'm wondering what might be downsides of "embed as library" approach? Is this recommended at all? What kind of issues we might expect?

P.S.: The only reference about auto-commit on each remote call is this example https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-examples/example-remotegraph/src/main/java/org/janusgraph/example/RemoteGraphApp.java#L61

Which a bit confusing, docs references about transaction local vs remote are a bit vague on subject.

[Florian Hockmann]

JanusGraph uses Gremlin Server as its server component. That is why you'll find documentation about these aspects in the TinkerPop docs:

http://tinkerpop.apache.org/docs/3.4.0/reference/#considering-transactions

downsides of "embed as library" approach? Is this recommended at all?

Disadvantages of JanusGraph embedded:

• You have both APIs available, the recommended Gremlin traversal API and the graph API that should only be used internally by JanusGraph itself. This often leads to confusion as people mix those two / don't know which to use.
• For some operations, all JanusGraph instances have to cooperate, e.g., for schema or some config changes. This becomes difficult to manage if you have multiple applications running with JanusGraph embedded as you can easily lose an overview over these applications.

Advantages of using JanusGraph Server instead of embedded:

• Clients from a variety of languages can access your graph.
• You have a central point to manage and monitor connections to your graph.
• The server does the transaction handling for you. You don't have to take care of that.
• Scaling: You can scale JanusGraph, your backend and your application independently of one another.
  

However, there are of course also some advantages of using JanusGraph embedded:

• You have access to the management API, e.g., to change the schema. (This could maybe also be seen as a disadvantage if you want a strict separation between applications and management of JanusGraph.)
• You can handle transactions manually.
• Less network round trips. This might offer a slightly better latency, although that should be really minimal.
• Less overhead as you don't get JanusGraph Server as an additional component to manage. (This is probably only an issue for very small applications.)

The overall recommendation is to use JanusGraph Server, unless you have really good reasons to use JanusGraph embedded.

[Ivan]

Thank you for pros and cons, really useful. I searched forum a bit and see people use both modes, so looks like need to create matrix and decide for use case.

>JanusGraph uses Gremlin Server as its server component. That is why you'll find documentation about these aspects in the TinkerPop docs:

Yes, I saw this doc - it talks about sessions and automated transaction managements, but from user/developer standpoint: is java client client API is sessionless? can you make it session aware like they mention in doc http://tinkerpop.apache.org/docs/3.4.0/reference/#sessions? Does janusgraph supports remote session aware clients? Should janusgraph doc about transactions have these details?

 >Clients from a variety of languages can access your graph.

If we are talking about microservices environment, having private graph behind some API is more desirable than shared graph db. For, lets say .net core, based service I would boostrap "service dedicated" graph instance. But it depends on scale of course.