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 >>>>> >>>> >> >>
