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