ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Transaction semantics questions
Date Wed, 08 Feb 2017 18:50:43 GMT
Thanks!

-Val

On Tue, Feb 7, 2017 at 8:43 PM, Yakov Zhdanov <yzhdanov@apache.org> 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 <
> valentin.kulichenko@gmail.com>:
>
> > 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message