Andrey, thanks for additional details. The doc is updated https://apacheignite.readme.io/docs/transactions#deadlock-detection-in-pessimistic-transactions <https://apacheignite.readme.io/docs/transactions#deadlock-detection-in-pessimistic-transactions>
— Denis > On May 23, 2016, at 2:28 PM, Andrey Gura <ag...@gridgain.com> wrote: > > 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
