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 <dsetrak...@apache.org> wrote: > On Fri, Sep 29, 2017 at 5:45 AM, Vladimir Ozerov <voze...@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 < > dsetrak...@apache.org> > > wrote: > > > > > On Thu, Sep 28, 2017 at 10:30 PM, Vladimir Ozerov < > voze...@gridgain.com> > > > wrote: > > > > > > > Dima, > > > > > > > > IgniteCache.withReadForUpdate() :-) > > > > > > > > > > And how is it better than a pessimistic transaction with read? > > > > > >
