You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by John Wilson <sa...@gmail.com> on 2018/02/13 06:49:33 UTC
Optimistic Locking and the Prepare Phase
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.
Re: Optimistic Locking and the Prepare Phase
Posted by Valentin Kulichenko <va...@gmail.com>.
John,
There is always a prepare phase during which locks are acquired and commit
phase during which changes are finalized and locks are released. The only
difference is that pessimistic transaction acquires each lock separately
while keys are accessed, but optimistic transaction runs the prepare phase
in one go before committing.
Imagine this simple transaction:
try (Transaction tx = txStart()) {
cache.put(1, 1);
cache.put(2, 2);
tx.commit();
}
Pessimistic will acquire lock for key 1 when first put is executed, then
acquire lock for key 2 when second put is executed, and then run the commit
phase during tx.commit().
Optimistic transaction will run both phases during tx.commit().
-Val
On Tue, Feb 13, 2018 at 6:10 AM, John Wilson <sa...@gmail.com>
wrote:
> Hi Vladimir,
>
> Your answer is what is depicted in the graphics and makes perfect sense to
> me. I guess what I'm confused about is what a "prepare" phase means and
> what "*In optimistic transactions, locks are acquired on primary nodes
> during the "prepare" phase* " means.
>
> My understanding of a "prepare" phase based on the blog here (
> https://www.gridgain.com/resources/blog/apache-ignite-
> transactions-architecture-2-phase-commit-protocol)
> is that it is the phase where we acquire all the necessary locks (in
> pessimistic locking) before we start the commit phase.
>
>
> 1. In the context of *pessimistic* locking, at the end of the prepare
> phase but before we start commit, we would have acquired all locks.
> True?
> 2. In the context of *optimistic* locking, a prepare phase would not
> request for or acquire locks. True?
> 3. In the context of *optimistic* locking, at the end of the prepare
> phase but before we start commit, we have stored the current version of
> the
> keys in the transaction coordinator but we have not yet requested or
> acquired any locks. Locks will be acquired during the commit phase.
> True?
>
> Thanks!
>
> On Tue, Feb 13, 2018 at 12:54 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > 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 <sa...@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.
> > >
> >
>
Re: Optimistic Locking and the Prepare Phase
Posted by John Wilson <sa...@gmail.com>.
Hi Vladimir,
Your answer is what is depicted in the graphics and makes perfect sense to
me. I guess what I'm confused about is what a "prepare" phase means and
what "*In optimistic transactions, locks are acquired on primary nodes
during the "prepare" phase* " means.
My understanding of a "prepare" phase based on the blog here (
https://www.gridgain.com/resources/blog/apache-ignite-transactions-architecture-2-phase-commit-protocol)
is that it is the phase where we acquire all the necessary locks (in
pessimistic locking) before we start the commit phase.
1. In the context of *pessimistic* locking, at the end of the prepare
phase but before we start commit, we would have acquired all locks. True?
2. In the context of *optimistic* locking, a prepare phase would not
request for or acquire locks. True?
3. In the context of *optimistic* locking, at the end of the prepare
phase but before we start commit, we have stored the current version of the
keys in the transaction coordinator but we have not yet requested or
acquired any locks. Locks will be acquired during the commit phase. True?
Thanks!
On Tue, Feb 13, 2018 at 12:54 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> 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 <sa...@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.
> >
>
Re: Optimistic Locking and the Prepare Phase
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <sa...@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.
>