Denis, I have made some minor edits. Please see if it makes sense.
Thanks, -Prachi On Wed, May 25, 2016 at 9:43 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > I would make deadlock-detection into a separate page. This way it will be > more prominent and easier to access. > > I think we can mention 2 topics on that page: > - deadlock-free transactions > - deadlock detection > > What do you think? > > D. > > On Wed, May 25, 2016 at 6:06 AM, Andrey Gura <ag...@gridgain.com> wrote: > > > 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 > > >
