ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Deadlock detection usage
Date Thu, 26 May 2016 05:37:40 GMT
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 <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