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 >
