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
>

Reply via email to