I think the whole point is to lock 1st and get 2nd. If you do a getAll, isn’t it possible that some value will be updated before you get it? If yes, then user’s logic will potentially be based on a wrong value, no?
D. On Thu, Feb 4, 2016 at 1:29 AM, Alexey Goncharuk <[email protected] > wrote: > If all keys are known in advance, how is it different from starting a > pessimistic transaction and invoking getAll() on those keys? Introducing a > new concept with such restrictions does not makes sense to me. > > 2016-02-04 1:27 GMT+03:00 Dmitriy Setrakyan <[email protected]>: > > > Igniters, > > > > I keep hearing questions from users about the snapshot isolation. > Currently > > ignite provides Optimistic and Pessimistic > > < > > > https://apacheignite.readme.io/docs/transactions#optimistic-and-pessimistic > > > > > transactions [1]. This modes ensure that transactional values are > > consistent with each other on 1st access of each value. > > > > However, some use cases require that transactional values are consistent > > with each other not at 1st access, but at transaction start time. After > > giving it some thought, I think we can support it with minimal effort, if > > we add a few restrictions. For example, we can easily support it if users > > specify all the keys at the beginning of the transaction, for example > > > > 1. User tells Ignite which keys he/she plans to transact on > > 2. Ignite preemptively acquires locks on all these keys > > 3. After locks are acquired, user has assurance that values will not > > change outside of this transaction and are consistent with teacher. > > 4. Locks are released upon commit > > > > The above algorithm will also perform better, as the initial looks will > be > > acquired in bulk, and not individually. > > > > Thoughts? > > > > [1] > > > https://apacheignite.readme.io/docs/transactions#optimistic-and-pessimistic > > >
