Hi, There is no example how to use it. It just works :)
For now deadlock detection supported only by pessimistic transactions with timeout. Near cache isn't supported. User should just start some pessimistic transactions with timeout and if timeout expired then deadlock detection will try to find deadlock. TransactionTimeoutException will be thrown and returned to user as cause of CacheException regardless of deadlock. But if deadlock detected then cause of this TransactionTimeoutException will be TransactionDeadlockException (at least for one transaction involved into deadlock). TransactionDeadlockException contains message like this: Deadlock detected: K1: TX1 holds lock, TX2 waits lock. K2: TX2 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, order=1463402198603, nodeOrder=1], nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=77] TX2 [txId=GridCacheVersion [topVer=74882201, time=1463402200675, order=1463402198604, nodeOrder=1], nodeId=46ef3b0a-dd48-434d-8151-d1af778fe180, threadId=78] Keys: K1 [key=1, cache=default] K2 [key=2, cache=default] I've created simple code example that creates deadlock and demonstrates result of deadlock detection [1]. There are a couple of system properties that allows manage deadlock detection: IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS and IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT. See IgniteSystemProperties class for props javadocs. [1] https://gist.github.com/agura/1e633b473188738aa3df7e1c6f9cc472 On Fri, May 13, 2016 at 3:04 PM, Denis Magda <dma...@gridgain.com> wrote: > Andrey, > > As I see you’ve implemented a deadlock detection mechanism recently > https://issues.apache.org/jira/browse/IGNITE-2854 > > Could you provide a basic example showing how to use it? I would like to > add the example and some words on the feature to readme. io so that the > communicate can leverage from this. > > — > Denis > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
