I think updating an Atomic cache from within a transaction perfectly makes
sense. For example for some kind of operations logging and so forth. Still
I agree that this can be error prone and forbidden by default. I agree with
Yakov that by default we should throw an exception and have some kind of
flag (on cache or on TX?) to be able to explicitly enable this behavior.
Sergi
2017-03-28 21:51 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> On Tue, Mar 28, 2017 at 11:42 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > 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.
> >
>
> Got it.
>
> But what if a user really needs to update an atomic cache from within some
> transactional logic? I think we should allow it, but print out an warning
> to the log on per-cache basis the first time we see some atomic cache used
> from within a transaction.
>
> D.
>
