I think an exception should be thrown if someone tries to start a transaction on an atomic cache. Throwing an exception at the "put(...)" time seems late and counter-intuitive.
However, if a user starts a transaction on a transactional cache, say CacheA, and inside that transaction updates an entry from a different atomic cache, say CacheB, then such update should be allowed in my view, because the transaction was started on a completely different cache. Does this make sense? D. On Tue, Mar 28, 2017 at 11:22 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > I actually think exception makes sense here. Currently it's very error > prone - the same code can behave differently depending on configuration. > And at the same time I can't imagine a use case which implies using atomic > operation within a transaction on purpose. If someone ever does this, it > would most likely be done by mistake. > > -Val > > On Tue, Mar 28, 2017 at 10:13 AM, Denis Magda <dma...@apache.org> wrote: > > > Yakov, > > > > My vote goes for the current behavior - an atomic operation is applied > > right away if it’s a part of a transaction. It’s better not to break > > compatibility here, there are already to many incompatible changes in > 2.0. > > > > — > > Denis > > > > > On Mar 28, 2017, at 3:08 AM, Yakov Zhdanov <yzhda...@apache.org> > wrote: > > > > > > As far as I know operations on atomic caches are applied immediately > > > dishonoring any tx context. > > > > > > I would suggest that atomic cache update operation called from active > tx > > > throws illegal state exception, unless user intentionally permits this > > > update by calling atomicCache.withAllowInTx() (similar to > > withSkipStore()). > > > > > > Thoughts? > > > > > > --Yakov > > > > >
