ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Future of Ignite transactions
Date Fri, 29 Sep 2017 13:00:56 GMT
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