Sir, yes, sir! Done ;) — Denis
> On May 27, 2016, at 2:52 PM, Andrey Gura <ag...@gridgain.com> wrote: > > Denis, > > one note from me: it would be great to add information block which states > that deadlock detection supports only pessimistic transaction now. > > Thanks. > > On Fri, May 27, 2016 at 2:14 PM, Denis Magda <dma...@gridgain.com> wrote: > >> Andrey, Dmitriy, thanks for the inputs. Considered them. >> >> Finally reworked/regrouped Transactions documentation [1], added table of >> contents, made some sections much clearer. >> >> [1] https://apacheignite.readme.io/v1.6/docs/transactions >> >> — >> Denis >> >>> On May 27, 2016, at 11:59 AM, Dmitriy Setrakyan <dsetrak...@apache.org> >> wrote: >>> >>> On Wed, May 25, 2016 at 10:37 PM, 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]? >>>> >>> >>> Sure, why not. >>> >>> >>>> >>>> [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
