Hi John, 1) In PESSIMISTIC mode locks are obtained either on first update (READ_COMMITTED) or even read (REPEATABLE_READ). I.e. they obtained before prepare phase and are held for the duration of transaction. In OPTIMISTIC mode locks are obtained only after you call IgniteTransaction.commit(). 2) It means that transaction will fail if enlisted entries have been changed after they were accessed by current transaction, but before this transaction is committed.
On Tue, Feb 13, 2018 at 9:49 AM, John Wilson <sami.hailu...@gmail.com> wrote: > Hi, > > The design doc below states: > > *" In optimistic transactions, locks are acquired on primary nodes during > the "prepare" phase, then promoted to backup nodes and released once the > transaction is committed. Depending on an isolation level, if Ignite > detects that a version of an entry has been changed since the time it was > requested by a transaction, then the transaction will fail at the "prepare" > phase and it will be up to an application to decide whether to restart the > transaction or not."* > > Two questions: > > > 1. If locks are acquired during the prepare phase, why do we state that > lock acquisition for optimistic locking is delayed (as compared against > pessimistic locking)? > 2. If "*ignite detects the version has changed since last request by > transaction, it will fail at prepare phase*". Very confusing. What is > the last request? I thought the "last request" means the "prepare" phase > and if so why we say it may fail during prepare phase? > > The graphic make sense to me - i.e. locks for optimistic locking are > acquired on the commit phase and not on the prepare phase. > > https://cwiki.apache.org/confluence/display/IGNITE/ > Ignite+Key-Value+Transactions+Architecture > > Please help clarify. > > Thanks. >
