Re: Concurrent Transactions on JG Edges

Aman <amandeep.srivastava1996@...>


Can someone please advise if previously mentioned way is incorrect for using lock consistencies on edge property keys (version in my case)?


On Mon, 10 Jan, 2022, 10:26 pm Aman via, <> wrote:
Hi Marc,

Thank you for your response. This is how I'm using it:

1. I created a property key called version, which is incremented at the service layer every time an update is made on an element (vertex or edge). 

mgmt = graph.openManagement()
version = mgmt.makePropertyKey('version').dataType(Integer.class).make()
mgmt.setConsistency(name, ConsistencyModifier.LOCK)
mgmt.buildIndex("vertexIndex", Vertex.class).addKey(version, Mapping.DEFAULT.asParameter()).buildMixedIndex("esIndex")
mgmt.buildIndex("edgeIndex", Edge.class).addKey(version, Mapping.DEFAULT.asParameter()).buildMixedIndex("esIndex")

In case mixed index already exists, I simply add the property in both vertex and edge mixed indices:
index = mgmt.getGraphIndex("edgeIndex or vertexIndex")
mgmt.addIndexKey(index, version)
In case

2. For every new edge label I create, I'm attaching this property to the edge.

mgmt = graph.openManagement() relatedTo = mgmt.makeEdgeLabel('relatedTo').make() mgmt.addProperties(relatedTo, version) mgmt.commit()

How I tested: When I'm making multiple concurrent calls via Jmeter to update an existing vertex, only one request passes, and rest throw a permanent locking exception. However, when I run same test for edges, multiple updates are successful. Few that fail are because of version check logic at service layer which kicks in a few ms after first few updates are successful.

I'm using Janus with Cassandra and Elastic Search.



Join { to automatically receive all group messages.