ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Future of Ignite transactions
Date Fri, 29 Sep 2017 13:05:42 GMT
I still have a feeling that we are fixing something that was not broken. I
have never heard from any user that they need to do both, blocking and
non-blocking reads in the same transaction.

The only requests I heard so far are:
- snapshot isolation
- read-only transactions

D.

On Fri, Sep 29, 2017 at 6:00 AM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Dima,
>
> My point was that we have a number of read-only methods and I do not want
> to pollute base cache API with their counterparts (get, getAll, getEntry,
> getEntries). Another point is that "pessimistic" reads is relatively rare
> use case comparing to "optimistic". This is why "with" approach looks
> better to me.
>
> Blocking reads doesn't make sense outside of explicit transaction.
>
> On Fri, Sep 29, 2017 at 3:47 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
> > On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > You can mix both "optimistic" and "pessimistic" reads in a single
> > > transaction. This is one of the main points of proposed API. Normally
> > users
> > > do not define blocking behavior on TX level. They do that on
> > per-operation
> > > level.
> > >
> >
> > In that case, why do you suggest the "with" API which will set this flag
> > for all operations. Why not just add "getWithLock()" method? Also, will
> > this method work on non-transactional caches?
> >
> >
> > >
> > > On Fri, Sep 29, 2017 at 3:30 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov <
> > vozerov@gridgain.com>
> > > > wrote:
> > > >
> > > > > Dima,
> > > > >
> > > > > IgniteCache.withReadForUpdate() :-)
> > > > >
> > > >
> > > > And how is it better than a pessimistic transaction with read?
> > > >
> > >
> >
>

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