[ https://issues.apache.org/jira/browse/IGNITE-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Denis Magda closed IGNITE-2426. ------------------------------- > Document optimisitic (deadlock-free) transactions on readme.io > -------------------------------------------------------------- > > Key: IGNITE-2426 > URL: https://issues.apache.org/jira/browse/IGNITE-2426 > Project: Ignite > Issue Type: Bug > Affects Versions: 1.5.0.final > Reporter: Denis Magda > Priority: Critical > Labels: important > Fix For: 1.6 > > Attachments: TransactionTest.java > > > There is a lack of documentation on how optimistic & serializable > transactions work. > Basic documentation has to be added covering some specific cases in addition. > As an example, the test attached demonstrates the following. > Both tasks update cache with put operations only without reading and keeping > entries's versions cause there is no any cache.get/getAll calls as a part of > the transaction. > Each transaction has it's unique ID. So at the commit time when one > transaction B tries to update an entry locking it before and sees that the > entry is locked by some transaction A, started earlier (have smaller > transaction ID), then transaction B will just wait until the lock is released > and can proceed with the commit later. If this repeats for every entry of > transactions and we haven't detected any conflict then both transactions > succeeds. This is exactly what happens sometimes in your test. > However, if the transactions were using cache.get or related operations then > during the commit time both transactions would be checking entry versions in > addition before proceeding with the commit. In general if an entry version at > commit time is different to the entry version at get time then a transaction > fails. To see this in practice use cache.getAndPut() instead of cache.put() > in the code. After applying this modification one of the transactions will > always fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)