ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Deadlock detection usage
Date Fri, 27 May 2016 08:59:52 GMT
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
> >>>
> >>
>
>

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