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
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
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[]>...
public async createManyByKey(label: string, key: string, properties: object[]): Promise<T[]>...
GitHub
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.
