Denis, great doc! Thanks!
On Tue, May 24, 2016 at 10:28 AM, Denis Magda <dma...@gridgain.com> wrote: > 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 > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
