Andrey,
As I see you’ve implemented a deadlock detection mechanism recently https://issues.apache.org/jira/browse/IGNITE-2854 <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 |
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 <[hidden email]> 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, 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://readme.io/> http://apacheignite.gridgain.org/v1.6/docs/transactions#deadlock-detection-in-pessimistic-transactions <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 <[hidden email]> 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 <https://gist.github.com/agura/1e633b473188738aa3df7e1c6f9cc472> > > > On Fri, May 13, 2016 at 3:04 PM, Denis Magda <[hidden email] <mailto:[hidden email]>> wrote: > Andrey, > > As I see you’ve implemented a deadlock detection mechanism recently > https://issues.apache.org/jira/browse/IGNITE-2854 <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 <http://www.gridgain.com/> |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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,
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > 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 > |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]> > > 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,
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]> > > 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 <[hidden email]> 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 <[hidden email]> > > > 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 > |
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 <[hidden email]> 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 <[hidden email]> 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 < > [hidden email]> > > 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 <[hidden email]> > 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 <[hidden email]> > > > 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 <[hidden email]> > 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 <[hidden email]> > > > > 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, 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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> 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 < >> [hidden email]> >>> 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 <[hidden email]> >> 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 <[hidden email]> >>>> 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 <[hidden email]> >> 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 <[hidden email]> >>>>> 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 |
Denis,
great doc! Thanks! On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> 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 <[hidden email]> 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 < > [hidden email]> > > 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 <[hidden email]> > 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 < > >> [hidden email]> > >>> 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 <[hidden email]> > >> 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 <[hidden email]> > >>>> 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 <[hidden email]> > >> 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 <[hidden email]> > >>>>> 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 |
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 <[hidden email]> wrote: > Denis, > > great doc! Thanks! > > On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> 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 <[hidden email]> 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 < > > [hidden email]> > > > 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 <[hidden email]> > > 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 < > > >> [hidden email]> > > >>> 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 <[hidden email]> > > >> 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 <[hidden email] > > > > >>>> 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 <[hidden email]> > > >> 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 <[hidden email] > > > > >>>>> 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 > |
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 <[hidden email]> 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 <[hidden email]> wrote: > > > Denis, > > > > great doc! Thanks! > > > > On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> > 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 <[hidden email]> 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 < > > > [hidden email]> > > > > 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 <[hidden email]> > > > 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 < > > > >> [hidden email]> > > > >>> 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 <[hidden email]> > > > >> 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 < > [hidden email] > > > > > > >>>> 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 <[hidden email]> > > > >> 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 < > [hidden email] > > > > > > >>>>> 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 > > > |
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 <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> wrote: >> >>> Denis, >>> >>> great doc! Thanks! >>> >>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> >> 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 <[hidden email]> 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 < >>>> [hidden email]> >>>>> 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 <[hidden email]> >>>> 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 < >>>>>> [hidden email]> >>>>>>> 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 <[hidden email]> >>>>>> 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 < >> [hidden email] >>>> >>>>>>>> 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 <[hidden email]> >>>>>> 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 < >> [hidden email] >>>> >>>>>>>>> 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 >>> >> |
From my point of view, "Transactions" topic is the most suitable place for
deadlock detection docs. The only thing that I don't like it topic name. I think that would be better just mention that detection supports only pessimistic transactions, because in the next release we will have deadlock detection for optimistic transactions also. So topic name should be jus "Deadlock detection". On Thu, May 26, 2016 at 8:37 AM, Denis Magda <[hidden email]> 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]? > > [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 <[hidden email]> 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 < > [hidden email]> > > 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 <[hidden email]> > wrote: > >> > >>> Denis, > >>> > >>> great doc! Thanks! > >>> > >>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> > >> 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 <[hidden email]> 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 < > >>>> [hidden email]> > >>>>> 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 <[hidden email]> > >>>> 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 < > >>>>>> [hidden email]> > >>>>>>> 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 <[hidden email]> > >>>>>> 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 < > >> [hidden email] > >>>> > >>>>>>>> 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 <[hidden email]> > >>>>>> 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 < > >> [hidden email] > >>>> > >>>>>>>>> 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 > >>> > >> > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com |
In reply to this post by Denis Magda
On Wed, May 25, 2016 at 10:37 PM, Denis Magda <[hidden email]> 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 <[hidden email]> 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 < > [hidden email]> > > 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 <[hidden email]> > wrote: > >> > >>> Denis, > >>> > >>> great doc! Thanks! > >>> > >>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> > >> 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 <[hidden email]> 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 < > >>>> [hidden email]> > >>>>> 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 <[hidden email]> > >>>> 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 < > >>>>>> [hidden email]> > >>>>>>> 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 <[hidden email]> > >>>>>> 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 < > >> [hidden email] > >>>> > >>>>>>>> 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 <[hidden email]> > >>>>>> 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 < > >> [hidden email] > >>>> > >>>>>>>>> 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 > >>> > >> > > |
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 <[hidden email]> wrote: > > On Wed, May 25, 2016 at 10:37 PM, Denis Magda <[hidden email]> 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 <[hidden email]> 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 < >> [hidden email]> >>> 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 <[hidden email]> >> wrote: >>>> >>>>> Denis, >>>>> >>>>> great doc! Thanks! >>>>> >>>>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> >>>> 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 <[hidden email]> 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 < >>>>>> [hidden email]> >>>>>>> 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 <[hidden email]> >>>>>> 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 < >>>>>>>> [hidden email]> >>>>>>>>> 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 <[hidden email]> >>>>>>>> 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 < >>>> [hidden email] >>>>>> >>>>>>>>>> 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 <[hidden email]> >>>>>>>> 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 < >>>> [hidden email] >>>>>> >>>>>>>>>>> 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 >>>>> >>>> >> >> |
Denis,
one note from me: it would be great to add information block which states that deadlock detection supports only pessimistic transaction now. Thanks. On Fri, May 27, 2016 at 2:14 PM, Denis Magda <[hidden email]> wrote: > 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 <[hidden email]> > wrote: > > > > On Wed, May 25, 2016 at 10:37 PM, Denis Magda <[hidden email]> > 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 <[hidden email]> 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 < > >> [hidden email]> > >>> 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 <[hidden email]> > >> wrote: > >>>> > >>>>> Denis, > >>>>> > >>>>> great doc! Thanks! > >>>>> > >>>>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> > >>>> 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 <[hidden email]> > 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 < > >>>>>> [hidden email]> > >>>>>>> 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 <[hidden email]> > >>>>>> 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 < > >>>>>>>> [hidden email]> > >>>>>>>>> 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 < > [hidden email]> > >>>>>>>> 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 < > >>>> [hidden email] > >>>>>> > >>>>>>>>>> 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 <[hidden email]> > >>>>>>>> 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 < > >>>> [hidden email] > >>>>>> > >>>>>>>>>>> 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 > >>>>> > >>>> > >> > >> > > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com |
Sir, yes, sir! Done ;)
— Denis > On May 27, 2016, at 2:52 PM, Andrey Gura <[hidden email]> wrote: > > Denis, > > one note from me: it would be great to add information block which states > that deadlock detection supports only pessimistic transaction now. > > Thanks. > > On Fri, May 27, 2016 at 2:14 PM, Denis Magda <[hidden email]> wrote: > >> 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 <[hidden email]> >> wrote: >>> >>> On Wed, May 25, 2016 at 10:37 PM, Denis Magda <[hidden email]> >> 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 <[hidden email]> 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 < >>>> [hidden email]> >>>>> 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 <[hidden email]> >>>> wrote: >>>>>> >>>>>>> Denis, >>>>>>> >>>>>>> great doc! Thanks! >>>>>>> >>>>>>> On Tue, May 24, 2016 at 10:28 AM, Denis Magda <[hidden email]> >>>>>> 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 <[hidden email]> >> 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 < >>>>>>>> [hidden email]> >>>>>>>>> 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 <[hidden email]> >>>>>>>> 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 < >>>>>>>>>> [hidden email]> >>>>>>>>>>> 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 < >> [hidden email]> >>>>>>>>>> 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 < >>>>>> [hidden email] >>>>>>>> >>>>>>>>>>>> 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 <[hidden email]> >>>>>>>>>> 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 < >>>>>> [hidden email] >>>>>>>> >>>>>>>>>>>>> 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 >>>>>>> >>>>>> >>>> >>>> >> >> > > > -- > Andrey Gura > GridGain Systems, Inc. > www.gridgain.com |
Free forum by Nabble | Edit this page |