You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when using the Berkeley backend, it is not possible to have concurrent transactions that do mutations on the same data, without getting PermanentStorageException (caused by sleepycat LockTimeOutException). That's because in the typical read-modify-write logic imposed by Titan, the concurrent transaction will deadlock when they try to promote their locks from READ to WRITE. (Which will lead to LockTimeoutException for all but one of the concurrent transactions).
The way to prevent these timeout exceptions is to use LockMode.RMW in transactions that mutate data. It's currently impossible to configure that with Titan.
In the transaction configuration, e.g. g.buildTransaction().setCustomOption("storage.lock-mode", "RMW").start().
In the graph configuration, e.g. storage.lock-mode=RMW in titan's properties file, which becomes the default LockMode for all transactions that don't specify their own LockMode as shown above.
Currently when using the Berkeley backend, it is not possible to have concurrent transactions that do mutations on the same data, without getting PermanentStorageException (caused by sleepycat LockTimeOutException). That's because in the typical read-modify-write logic imposed by Titan, the concurrent transaction will deadlock when they try to promote their locks from READ to WRITE. (Which will lead to LockTimeoutException for all but one of the concurrent transactions).
The way to prevent these timeout exceptions is to use LockMode.RMW in transactions that mutate data. It's currently impossible to configure that with Titan.
This is request is related to #71.
The text was updated successfully, but these errors were encountered: