Dmitry, Do you think that we should configure deadlock detection using cache configuration?
User should have possibility to have control over this process because it blocks transaction until detection completion. You are right. Deadlock detection starts after transaction timeout and lists transactions and keys involved into deadlock in exception message. On Fri, May 20, 2016 at 3:16 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Andrey, > > Why are we using system properties for the deadlock detection > configuration? Also, why would a user want to interrupt the deadlock > detection process? > > To my knowledge, the deadlock detection process should run after > transaction has timed out and should include the deadlocked keys into the > timeout exception message. Am I wrong? > > D. > > On Wed, May 18, 2016 at 9:38 AM, Andrey Gura <ag...@gridgain.com> wrote: > > > Deadlock detection is multi step procedure where steps amount depends on > > amount of nodes in cluster, keys and transactions that involved into > > deadlock. Deadlock detection initiator is a node on whicn transaction was > > started and timeouted. So this node tries to untangle deadlock step by > step > > where each step it is usually request to remote node. So onle > > request/response cycle is an iteration. > > > > Amount of keys, transactions and nodes may be too big. Moreover, > > transaction timeout does not mean that deadlock actually exists. So user > > can limit amount of iterations that deadlock detection performs using > > IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS system property. User also can > > switch off deadlock detection using non positive value for this property. > > > > IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT allows to inerrupt deadlock > detection > > process after specified amount of time. It is another way to limit time > of > > execution of deadlock detection process. > > > > > > > > On Tue, May 17, 2016 at 10:51 AM, Denis Magda <dma...@gridgain.com> > wrote: > > > > > Andrey, perfect! Thanks a lot for the explanation. > > > > > > I’ve created a documentation for this functionality and added it to 1.6 > > > version of readme.io > > > > > > > > > http://apacheignite.gridgain.org/v1.6/docs/transactions#deadlock-detection-in-pessimistic-transactions > > > > > > Please feel free to improve it if needed. > > > > > > However, I would add more technical details on how the deadlock > detection > > > procedure works because presently it’s not clear why user need to > modify > > > these properties - IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS and > > > IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT. > > > > > > Could you elaborate on the procedure more technically so that its clear > > > why these properties are needed? > > > > > > — > > > Denis > > > > > > On May 16, 2016, at 3:47 PM, Andrey Gura <ag...@gridgain.com> wrote: > > > > > > Hi, > > > > > > There is no example how to use it. It just works :) > > > > > > For now deadlock detection supported only by pessimistic transactions > > with > > > timeout. Near cache isn't supported. > > > > > > User should just start some pessimistic transactions with timeout and > if > > > timeout expired then deadlock detection will try to find deadlock. > > > TransactionTimeoutException will be thrown and returned to user as > cause > > > of CacheException regardless of deadlock. But if deadlock detected then > > > cause of this TransactionTimeoutException will be > > > TransactionDeadlockException (at least for one transaction involved > into > > > deadlock). TransactionDeadlockException contains message like this: > > > > > > Deadlock detected: > > > > > > K1: TX1 holds lock, TX2 waits lock. > > > K2: TX2 holds lock, TX1 waits lock. > > > > > > Transactions: > > > > > > TX1 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, > > > order=1463402198603, nodeOrder=1], > > > nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=77] > > > TX2 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, > > > order=1463402198604, nodeOrder=1], > > > nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=78] > > > > > > Keys: > > > > > > K1 [key=1, cache=default] > > > K2 [key=2, cache=default] > > > > > > I've created simple code example that creates deadlock and demonstrates > > > result of deadlock detection [1]. > > > > > > There are a couple of system properties that allows manage deadlock > > > detection: IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS and > > > IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT. See IgniteSystemProperties class > > for > > > props javadocs. > > > > > > [1] https://gist.github.com/agura/1e633b473188738aa3df7e1c6f9cc472 > > > > > > > > > On Fri, May 13, 2016 at 3:04 PM, Denis Magda <dma...@gridgain.com> > > wrote: > > > > > >> Andrey, > > >> > > >> As I see you’ve implemented a deadlock detection mechanism recently > > >> https://issues.apache.org/jira/browse/IGNITE-2854 > > >> > > >> Could you provide a basic example showing how to use it? I would like > to > > >> add the example and some words on the feature to readme. io so that > the > > >> communicate can leverage from this. > > >> > > >> — > > >> Denis > > >> > > > > > > > > > > > > -- > > > Andrey Gura > > > GridGain Systems, Inc. > > > www.gridgain.com > > > > > > > > > > > > > > > -- > > Andrey Gura > > GridGain Systems, Inc. > > www.gridgain.com > > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
