ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Garg <pg...@gridgain.com>
Subject Re: Deadlock detection usage
Date Wed, 25 May 2016 22:42:21 GMT
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