>From my point of view, "Transactions" topic is the most suitable place for deadlock detection docs.
The only thing that I don't like it topic name. I think that would be better just mention that detection supports only pessimistic transactions, because in the next release we will have deadlock detection for optimistic transactions also. So topic name should be jus "Deadlock detection". On Thu, May 26, 2016 at 8:37 AM, Denis Magda <dma...@gridgain.com> wrote: > Parchi, > > Thanks a lot for the editing! > > Dmitriy, > > Maybe it’s better to introduce a table of content to Transactions > documentation like it’s done for JVM tuning [1]? > > [1] https://apacheignite.readme.io/docs/jvm-and-system-tuning < > https://apacheignite.readme.io/docs/jvm-and-system-tuning> > > > On May 26, 2016, at 1:42 AM, Prachi Garg <pg...@gridgain.com> wrote: > > > > 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 > >>> > >> > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
