Deadlock when concurrent node modification in berkeley #1623
Labels
Comments
|
Hi, I have a similar issue but the error is not exactly the same Which is identical to this old issue with Titan This is with the latest version of Janus and Berkely available. |
|
Any update or plan on fixing this? |
|
Any update on this. I am facing the same Lock issue in janus with berkeley on version 0.5.3. I just did the work around by setting isolation level as READ_UNCOMMITTED This is not happening in Janus 0.4.0 |
|
Using JanusGraph 0.6.3 with berkleyje we are running into the same problems. Actually can reproduce both, deadlock and locktimeout. Lock mode and isolation level are used synonymously in this thread, but there are two berkley related Janusgraph options, so I am not sure which are meant. But even if we set both like this in The issues still remain. Only by changing EnvironmentConfig.LOCK_TIMEOUT (additionally) things change. Sadly, not found a way to do this programatically, as JanusGraph is not exposing the |
|
Few details on the deadlock situation. We encountered this only if we have two concurrent transactions which both first read and then update properties of an identical set of vertices (code on our side was an error, so deadlock is not as much an issue for us atm). Not sure if the transaction system should handle this case or the deadlock is expected, but just for completeness here is the stracktrace: As for the locktimeout issue, this went away removing the lock timeout (and nothing froze). Here is our stacktrace for diagnosis: |
|
Sadly, we encountered different exceptions after applying the workarounds (remove locktimeout, set configuration to READ_UNCOMMITTED). As a first intuition I think they all are happening when JanusGraph is implicitly creating the schema in a concurrent setting. It seems they all go away if we do not rely on implicit schema creation and generate the schema beforehand, but importantly only single threaded, so not concurrently. In that case so far we havent seen the numerous errors which I will post below. So, I guess JanusGraph has some problems with automatic schema creation either only with the lock modes READ_UNCOMMITTED or in general with the berkleyje backend... So here are all the stacktraces we encountered when JanusGraph had to automatically create the schema inside the concurrent transactions: |
porunov
added a commit
to porunov/janusgraph
that referenced
this issue
Oct 17, 2024
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <alexandr.porunov@gmail.com>
porunov
added a commit
to porunov/janusgraph
that referenced
this issue
Oct 17, 2024
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <alexandr.porunov@gmail.com>
porunov
added a commit
to porunov/janusgraph
that referenced
this issue
Oct 17, 2024
…s [tp-tests] Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <alexandr.porunov@gmail.com>
|
Created PR #4701 which exposes all BerkeleyJE config options to the user. This may help configuring necessary timeouts as well as other options. |
porunov
added a commit
to porunov/janusgraph
that referenced
this issue
Oct 18, 2024
Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <alexandr.porunov@gmail.com>
porunov
added a commit
to porunov/janusgraph
that referenced
this issue
Oct 27, 2024
Related to JanusGraph#1623 and JanusGraph#4425 Signed-off-by: Oleksandr Porunov <alexandr.porunov@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Example of code
Exception
For fix it, change default isolation level (LOCK_MODE) to LockMode.READ_UNCOMMITTED
But if we want to use default lock mode, we can increase EnvironmentConfig.LOCK_TIMEOUT (default 500ms), so another way to fix that make it parametr customizable
The text was updated successfully, but these errors were encountered: