AT

Apache TinkerPop•3y ago•

8 replies

edolivares

Coalesce steps causing concurrency issues

I’ve been having some issues with concurrnt modification errors on AWS Neptune. I’ve tried lowering the reserve concurrency but, the issue persists. Based on https://stackoverflow.com/questions/69932798/concurrentmodificationexception-in-amazon-neptune-using-gremlin-javascript-langu I was wondering if I could split up my use-case into two queries the first a g.V().has({my unique property})… and if it’s null only then do I do the mutation step. I’m kind of confused why this would make a difference though.

This is my use-case (gremlinStatistics is how I imported __ for anonymous traversals, I’ll be changing that haha)


collection = await gremlinConnection
.V()
.hasLabel('collection')
.has('id', conceptId)
.fold()
.coalesce(
gremlinStatistics.unfold(),
addVCommand
)
.next()


https://github.com/nasa/Common-Metadata-Repository/blob/master/graph-db/serverless/src/utils/cmr/indexCmrCollection.js

Stack Overflow

ConcurrentModificationException in amazon neptune using gremlin jav...

I am trying to check and insert 1000 vertices in chunk using promise.all(). The code is as follows:
public async createManyByKey(label: string, key: string, properties: object[]): Promise<T[]>...

GitHub

Common-Metadata-Repository/indexCmrCollection.js at master · nasa/C...

Contribute to nasa/Common-Metadata-Repository development by creating an account on GitHub.

Solution

In general the CME is a retryable exception, and in a highly concurrent environment where multiple client threads are mutating the graph at more or less the same time they are likely to happen and should be expected / coded for. That said, as much as possible having each client thread be touching different parts of the graph can reduce the likelihood of lock contentions.

Jump to solution