ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: snapshot transaction isolation
Date Thu, 04 Feb 2016 09:53:38 GMT
> 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 approach.

> 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

I think that it will also be very good to add tx-awareness to cache lock we
currently have. GETALL may be very heavy which may not be needed + we
support all TX not only pessimistic. So, the logic will be:

START_TX()

LOCK_ALL(KEYS);

INVOKE/PUT/GET/ETC

COMMIT()/ROLLBACK()


--Yakov

2016-02-04 12:31 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> 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 <
> alexey.goncharuk@gmail.com
> > 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 <dsetrakyan@apache.org>:
> >
> > > 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message