+ 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 < valentin.kuliche...@gmail.com>: > Thanks! > > -Val > > On Tue, Feb 7, 2017 at 8:43 PM, Yakov Zhdanov <yzhda...@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.kuliche...@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 > > > > > >
