ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Дмитрий Рябов <somefire...@gmail.com>
Subject Re: IGNITE-4188, savepoints with atomic cache?
Date Wed, 05 Apr 2017 19:52:38 GMT
IGNITE-2313 done, can you review it?

PR: https://github.com/apache/ignite/pull/1709/files
JIRA: https://issues.apache.org/jira/browse/IGNITE-2313
CI: http://ci.ignite.apache.org/viewType.html?buildTypeId=
IgniteTests_RatJavadoc&branch_IgniteTests=pull%2F1709%
2Fhead&tab=buildTypeStatusDiv

2017-03-29 20:58 GMT+03:00 Denis Magda <dmagda@apache.org>:

> Sorry, I get lost in tickets.
>
> Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this
> change.
>
> —
> Denis
>
> > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов <somefireone@gmail.com>
> wrote:
> >
> > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make
> > exceptions first?
> >
> > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов <somefireone@gmail.com>:
> >
> >> Finish savepoints or flag&exceptions for atomic operations?
> >> Not sure about savepoints. Exceptions - yes. https://issues.apache.
> >> org/jira/browse/IGNITE-2313 isn't it?
> >>
> >> 2017-03-29 2:12 GMT+03:00 Denis Magda <dmagda@apache.org>:
> >>
> >>> If we want to make the exception based approach the default one then
> the
> >>> task has to be released in 2.0.
> >>>
> >>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the
> >>> code freeze data (April 14)?
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> >>> wrote:
> >>>>
> >>>> On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin <
> >>> sergi.vladykin@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> 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.
> >>>>>
> >>>>
> >>>>
> >>>> Agree, this sounds like a good idea.
> >>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message