Transaction semantics questions

[Valentin Kulichenko]

Folks,

I've got couple of questions about transactional behavior in Ignite that I
want to clarify.

1. With READ_COMMITTED isolation, do I have atomicity guarantee when
reading multiple values? For example, first transaction commits keys
[1,2,3,4,5], while another does getAll([2,4]). Is it possible to get
committed value for 2 and an old one for 4, or vice versa? Is there a
difference between a distributed transaction and transaction colocated to a
single node?

2.  What are the semantics of PRIMARY_SYNC in transactional cache? Is there
a difference in guarantees between PRIMARY_SYNC and FULL_SYNC?

Thanks!

-Val

[yzhdanov]

Val, I think value read which is about to be overwritten by a commit is
possible. I think only pessimistic repeatable read tx can protect you
against that. Also, it seems there are no difference between read from one
node and read from several nodes here.

In primary_sync mode primaries send finish response immediately after
processing finish request. Prepare step is synchronous (successful
completion of one, btw, ensures that TX will be committed in any case). For
FULL_SYNC primary nodes wait for all backups and near readers to respond to
finish and then send finish responses back to near node.

--Yakov

2017-02-08 11:23 GMT+07:00 Valentin Kulichenko <
[hidden email]>:

> Folks,
>
> I've got couple of questions about transactional behavior in Ignite that I
> want to clarify.
>
> 1. With READ_COMMITTED isolation, do I have atomicity guarantee when
> reading multiple values? For example, first transaction commits keys
> [1,2,3,4,5], while another does getAll([2,4]). Is it possible to get
> committed value for 2 and an old one for 4, or vice versa? Is there a
> difference between a distributed transaction and transaction colocated to a
> single node?
>
> 2.  What are the semantics of PRIMARY_SYNC in transactional cache? Is there
> a difference in guarantees between PRIMARY_SYNC and FULL_SYNC?
>
> Thanks!
>
> -Val
>

[Valentin Kulichenko]

Thanks!

-Val

On Tue, Feb 7, 2017 at 8:43 PM, Yakov Zhdanov <[hidden email]> wrote:

> Val, I think value read which is about to be overwritten by a commit is
> possible. I think only pessimistic repeatable read tx can protect you
> against that. Also, it seems there are no difference between read from one
> node and read from several nodes here.
>
> In primary_sync mode primaries send finish response immediately after
> processing finish request. Prepare step is synchronous (successful
> completion of one, btw, ensures that TX will be committed in any case). For
> FULL_SYNC primary nodes wait for all backups and near readers to respond to
> finish and then send finish responses back to near node.
>
> --Yakov
>
> 2017-02-08 11:23 GMT+07:00 Valentin Kulichenko <
> [hidden email]>:
>
> > Folks,
> >
> > I've got couple of questions about transactional behavior in Ignite that
> I
> > want to clarify.
> >
> > 1. With READ_COMMITTED isolation, do I have atomicity guarantee when
> > reading multiple values? For example, first transaction commits keys
> > [1,2,3,4,5], while another does getAll([2,4]). Is it possible to get
> > committed value for 2 and an old one for 4, or vice versa? Is there a
> > difference between a distributed transaction and transaction colocated
> to a
> > single node?
> >
> > 2.  What are the semantics of PRIMARY_SYNC in transactional cache? Is
> there
> > a difference in guarantees between PRIMARY_SYNC and FULL_SYNC?
> >
> > Thanks!
> >
> > -Val
> >
>

[Alexey Goncharuk]

+ My 5 cents:

When a transaction uses one-phase commit optimization, there is no
difference between PRIMARY_SYNC and FULL_SYNC.

2017-02-08 21:50 GMT+03:00 Valentin Kulichenko <
[hidden email]>:

> Thanks!
>
> -Val
>
> On Tue, Feb 7, 2017 at 8:43 PM, Yakov Zhdanov <[hidden email]> wrote:
>
> > Val, I think value read which is about to be overwritten by a commit is
> > possible. I think only pessimistic repeatable read tx can protect you
> > against that. Also, it seems there are no difference between read from
> one
> > node and read from several nodes here.
> >
> > In primary_sync mode primaries send finish response immediately after
> > processing finish request. Prepare step is synchronous (successful
> > completion of one, btw, ensures that TX will be committed in any case).
> For
> > FULL_SYNC primary nodes wait for all backups and near readers to respond
> to
> > finish and then send finish responses back to near node.
> >
> > --Yakov
> >
> > 2017-02-08 11:23 GMT+07:00 Valentin Kulichenko <
> > [hidden email]>:
> >
> > > Folks,
> > >
> > > I've got couple of questions about transactional behavior in Ignite
> that
> > I
> > > want to clarify.
> > >
> > > 1. With READ_COMMITTED isolation, do I have atomicity guarantee when
> > > reading multiple values? For example, first transaction commits keys
> > > [1,2,3,4,5], while another does getAll([2,4]). Is it possible to get
> > > committed value for 2 and an old one for 4, or vice versa? Is there a
> > > difference between a distributed transaction and transaction colocated
> > to a
> > > single node?
> > >
> > > 2.  What are the semantics of PRIMARY_SYNC in transactional cache? Is
> > there
> > > a difference in guarantees between PRIMARY_SYNC and FULL_SYNC?
> > >
> > > Thanks!
> > >
> > > -Val
> > >
> >
>