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