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 Fri, 27 May 2016 11:14:36 GMT
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
>>>>> 
>>>> 
>> 
>> 


Mime
View raw message