Re: Deadlock detection usage

Sir, yes, sir! Done ;) — Denis > On May 27, 2016, at 2:52 PM, Andrey Gura 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,

Re: Deadlock detection usage

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

Re: Deadlock detection usage

>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

Re: Deadlock detection usage

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

Re: Deadlock detection usage

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 wrote: > I would make deadlock-detection into a separate page. This way it will be > more prominent and easier to access. > > I think we

Re: Deadlock detection usage

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

Re: Deadlock detection usage

Denis, great doc! Thanks! On Tue, May 24, 2016 at 10:28 AM, Denis Magda wrote: > Andrey, thanks for additional details. The doc is updated > > https://apacheignite.readme.io/docs/transactions#deadlock-detection-in-pessimistic-transactions > < >

Re: Deadlock detection usage

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

Re: Deadlock detection usage

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 wrote: > Dmitry, > > Do you think that we should configure deadlock

Re: Deadlock detection usage

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

Re: Deadlock detection usage

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

Re: Deadlock detection usage

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

Re: Deadlock detection usage

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