Dmitry,
Transaction is not started on a particular cache, it's separate top-level
API. You can then include operations on different caches, like this:
try (Transaction tx = ignite.transactions.txStart()) {
cache1.put(..);
cache2.put(..);
cache3.put(..);
tx.commit();
}
In the code above it's easy to think that all three operations are enlisted
in transaction, but if one of the caches happens to be atomic (due to
misconfiguration, for example), that's actually not true. And we don't even
warn user about this.
-Val
On Tue, Mar 28, 2017 at 11:28 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> 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
> > >
> > >
> >
>
