Concurrent MergeV gremlingo - Vertex Id exists
If I use more than one go routine to update the gremlin server, so each has its own connection and traversal, then use MergeV using the gremlingo.T.Id as the merge match property set, I can occasionally get an error that "A vertex with id xxx-ssss-ssss-sss already exists". I have both Merge options specified.
This makes me think that the server cannot support more than one concurrent MergeV to the same VertexId. Is that correct, or is there some configuration I should be doing to make them lock?
A single threaded run works as expected.
5 Replies
I think that the answer might be graph dependent. what graph database are you using with Gremlin Server?
Sorry - should have been more specific, just the Tinkerpop Java gremlin server. I have yet to try that code on Neptune, which is the real target.
This seems to come from the MergeV creating the actual vertex while a MergeV to create a place holder for a MergeE is also creating it. One of them wins then the other says that it already exists because I am specifying the vertex id.
Probably the easiest solution might be for me to create all the vertices that will be targets of edges first. I can do that because I know what I am importing and can then avoid teh MergeV to create the edges.
So for Gremlin Server with TinkerGraph I could see you having this problem. TinkerGraph isn't really good for multi-threaded writes right now so if two
mergeV() hit at the same time, you can get some odd behavior and i think that goes for any mutation at all like addV(). We generally don't recommend that you write to TinkerGraph with multiple threads. This doesn't leave TinkerGraph without many production use cases, but this one isn't one of them.
@valentyn_kahamlyk will there be any changes in behavior with respect to this scenario given that you are currently adding transactions to TinkerGraph?there is a change, but in the other direction. There should be an error for any attempt to change the same element in different transactions
OK - no problem. I just needed to know that this was the case and not my code having some race condition that I was not detecting. I belive that Neptune is OK with this as it does seem to lock the vertices. This is part of a batch import program, which will move to generating batch import files for Neptune anyway. The TinkerGraph is just used to make local development a bit easier. Thanks for the information.