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 <voze...@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 <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? > > > > > > > > > >
