[ https://issues.apache.org/jira/browse/IGNITE-21572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Denis Chudov updated IGNITE-21572: ---------------------------------- Reviewer: Alexander Lapin > One phase transacion protocol is inconsistent in case of primary replica > expirations > ------------------------------------------------------------------------------------ > > Key: IGNITE-21572 > URL: https://issues.apache.org/jira/browse/IGNITE-21572 > Project: Ignite > Issue Type: Bug > Reporter: Alexander Lapin > Assignee: Denis Chudov > Priority: Critical > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > Consider following scenario: > # Full (1PC) transaction tx1 starts on PrimaryReplica1 [leaseholder='X', > startTime='t1', endTime='t10'] > # Within a given 1PC transaction 2-phase operation is evaluated over key1, > e.g. replace or increment (we do not have increment operation, however it's > easy to explain the problem with it, so let's assume that we have one). > # Within increment processing, processor acquires lock on key1, reads the > corresponding value and is about to write the new one. > # At this point, PrimaryReplica leaseholder='X' expires. > # Another transaction tx2 starts on new PrimaryReplica2 [leaseholder='Y', > startTime='t11', endTime='t21']. > # Within tx2 user also calls increment, thus also acquires lock, reads old > value and writes new one. > # tx2 finishes. > # tx1 successfully writes tx1.newValue overriding the value from tx2. > All in all, because tx2 didn't see tx1 locks because primary was changes > instead of (key1+{+}){+}+ transactions will finish with (key1)++ which is of > course not valid. > h3. Definition of Done > * Bug is fixed. > h3. Implementation Notes > * As a fast fix we should use 1PC(full) transactions only in case of > one-phase operation, like put. All two-phase operations like replica, > deleteExact, etc should be evaluated within a common 2PC transaction. > * Besides fast fix, we should consider supporting invoke as a raft command > that will effectively convert read+write to an atomic operation. -- This message was sent by Atlassian Jira (v8.20.10#820010)