ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@gridgain.com>
Subject Re: Deadlock detection usage
Date Fri, 27 May 2016 11:52:50 GMT
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 <dmagda@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 <dsetrakyan@apache.org>
> wrote:
> >
> > On Wed, May 25, 2016 at 10:37 PM, Denis Magda <dmagda@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 <pgarg@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 <
> >> dsetrakyan@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 <agura@gridgain.com>
> >> wrote:
> >>>>
> >>>>> Denis,
> >>>>>
> >>>>> great doc! Thanks!
> >>>>>
> >>>>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <dmagda@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 <agura@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 <
> >>>>>> dsetrakyan@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 <agura@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
<
> >>>>>>>> dsetrakyan@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
<
> agura@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 <
> >>>> dmagda@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 <agura@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 <
> >>>> dmagda@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message