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