Denis Magda created IGNITE-2426:
-----------------------------------
Summary: 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
Reporter: Denis Magda
Priority: Critical
Fix For: 1.6
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)
