Re: snapshot transaction isolation

Hm… how about allowing to acquire locks within a transaction and just releasing locks on transaction commit? It won’t break current compatibility because we simply do not allow acquiring locks within transactions right now. I am wrong? D. On Mon, Feb 8, 2016 at 4:10 AM, Alexey Goncharuk

Re: snapshot transaction isolation

Currently lock-only functionality is exposed via j.u.c.Lock interface on IgniteCache. We have two choices here: * Release such locks on transaction commit, which would break the contract of j.u.c.Lock * Do not release such locks on transaction commit, which, in my opinion, conflicts with the

Re: snapshot transaction isolation

+1 This should help us with IGFS performance as we currently use getAll() in PESSIMISTIC mode mainly to lock keys, not to get their values. On Thu, Feb 4, 2016 at 12:56 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > So, basically, we want to add lockAll() method that locks entries

Re: snapshot transaction isolation

In PESSIMISTIC transaction a value is always read after a lock is acquired, so a locked value cannot be updated. Am I missing something? Do you have a specific scenario in mind?

Re: snapshot transaction isolation

> 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? 1. What if any value gets updated before you lock it? It seems this is the strongest guarantee we can provide with this

Re: snapshot transaction isolation

So, basically, we want to add lockAll() method that locks entries without returning their values to a client - this is a good idea. I do not want, however, to call it SNAPSHOT isolation, because this is not what it is.

Re: snapshot transaction isolation

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 : > Igniters, > > I

Re: snapshot transaction isolation

On Thu, Feb 4, 2016 at 1:56 AM, Alexey Goncharuk wrote: > So, basically, we want to add lockAll() method that locks entries without > returning their values to a client - this is a good idea. I do not want, > however, to call it SNAPSHOT isolation, because this is

snapshot transaction isolation

Igniters, I keep hearing questions from users about the snapshot isolation. Currently ignite provides Optimistic and Pessimistic transactions [1]. This modes ensure that transactional values are consistent with each