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 <[email protected]> wrote: > Denis, > > great doc! Thanks! > > On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[email protected]> 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 <[email protected]> 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 < > > [email protected]> > > > 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 <[email protected]> > > 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 < > > >> [email protected]> > > >>> 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 <[email protected]> > > >> 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 <[email protected] > > > > >>>> 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 <[email protected]> > > >> 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 <[email protected] > > > > >>>>> 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 >
