[jira] [Commented] (IGNITE-1607) Implement deadlock-free optimistic serializable mode

["Semen Boikov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978034#comment-14978034 ] 

Semen Boikov commented on IGNITE-1607:
--------------------------------------

Initialy proposed implementation when transaction is cancelled if there is already MVCC candidate does not work well when two transactions have lot of intersecting keys: it is possible that these transaction will constantly conflict and will both constantly fail with TransactionOptimisticException.

It was decided to implement another approach which allows not fail all conflicting transactions:
- all transactions are ordered by unique nearXidVersion (first compare globalTime, then node order, then localOrder)
- per-entry MVCC candidate queue with waiting transactions is sorted by nearXidVersion
- when transaction tries to acquire entry lock it is added in waiting queue if queue is empty or last waiting transaction have lower order, otherwise transaction fails

With this approach transaction lock assignment is ordered and transactions with lower order never wait for transactions with greater order, so this algorithm should not cause deadlocks.

> Implement deadlock-free optimistic serializable mode
> ----------------------------------------------------
>
>                 Key: IGNITE-1607
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1607
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: ignite-1.4
>            Reporter: Alexey Goncharuk
>            Assignee: Semen Boikov
>             Fix For: 1.5
>
>
> There is an idea of optimistic serializable mode which will provide better scalability on relatively large transactions and large topologies when no heavy contention is experienced.
>  * When transactional read is performed, we need to store the version of read entry.
>  * When transaction prepare is performed, we can send prepare requests simultaneously on all nodes. There is no need to preserve the order of locks and create a queue of tx mappings for this mode.
>  * When we add local MVCC candidates on a primary node, two checks are performed: that the current entry version matches the one transaction read (if read was performed), and that currently there are no other local MVCC candidates. If any of these checks fails, prepare step fails and transaction is failed with optimistic conflict exception.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)