Dmitry, In this case "blocked" means that transaction can't be rolled back while deadlock detection isn't completed. As soon as detection completes transaction can be rolled back and, for example, retried.
So in cases when deadlock detection is switched off transactions will be just rolled back immediately with TransactionTimeoutException, while with deadlock detection they will be blocked during deadlock detection procedure execution. On Mon, May 23, 2016 at 12:30 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > 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 > > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
