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 > > >
