Andrey, Can you tell me what transaction is being blocked? If it is the transaction in deadlock, then I think it should not matter, as it is blocked anyway.
D. On Sun, May 22, 2016 at 2:11 PM, Andrey Gura <ag...@gridgain.com> wrote: > 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 >
