[
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)
