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 <ag...@gridgain.com> wrote: > > Hi, > > There is no example how to use it. It just works :) > > For now deadlock detection supported only by pessimistic transactions with > timeout. Near cache isn't supported. > > User should just start some pessimistic transactions with timeout and if > timeout expired then deadlock detection will try to find deadlock. > TransactionTimeoutException will be thrown and returned to user as cause of > CacheException regardless of deadlock. But if deadlock detected then cause of > this TransactionTimeoutException will be TransactionDeadlockException (at > least for one transaction involved into deadlock). > TransactionDeadlockException contains message like this: > > Deadlock detected: > > K1: TX1 holds lock, TX2 waits lock. > K2: TX2 holds lock, TX1 waits lock. > > Transactions: > > TX1 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, > order=1463402198603, nodeOrder=1], > nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=77] > TX2 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, > order=1463402198604, nodeOrder=1], > nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=78] > > Keys: > > K1 [key=1, cache=default] > K2 [key=2, cache=default] > > I've created simple code example that creates deadlock and demonstrates > result of deadlock detection [1]. > > There are a couple of system properties that allows manage deadlock > detection: IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS and > IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT. See IgniteSystemProperties class for > props javadocs. > > [1] https://gist.github.com/agura/1e633b473188738aa3df7e1c6f9cc472 > <https://gist.github.com/agura/1e633b473188738aa3df7e1c6f9cc472> > > > On Fri, May 13, 2016 at 3:04 PM, Denis Magda <dma...@gridgain.com > <mailto:dma...@gridgain.com>> 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/>
