Hi, Please, imagine a possible case: 1. Atomic cache exists for a function that doesn't require strong guarantees, like audit or counter. 2. Put for such cache is implemented as a processor that is built-in to a spring annotation (some meaningful method is annotated with it). 3. The meaningful method is invoked within a transaction.
For such users there is a cost for re-writing such a code. Let's provide an opportunity for such behaviour, even if it isn't fully correct. On Fri, Oct 28, 2022 at 5:25 PM Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > Changing the atomic caches in a transaction is really weird, so I would > remove the property as well and retain only the safe behavior. > If you want to update an atomic cache, do it before or after a transaction. > > пт, 28 окт. 2022 г. в 13:06, Maksim Timonin <timoninma...@apache.org>: > > > Hi, all! > > > > In private discussion with Ivan Daschinsky and Anton Vinogradov we > > discussed optional scenarios when such a situation is possible. > > > > Then I agree with Stan's proposal: > > 1. Revert deprecation. > > 2. Change default value in 2.15. > > 3. Notify users in release notes, an exception message - how to change > the > > behavior back. > > > > If there are no objections, I'll revert a commit on Monday. > > > > Thanks! > > > > > > On Tue, Oct 25, 2022 at 3:43 PM Maksim Timonin <timoninma...@apache.org> > > wrote: > > > > > Hi, Stan! > > > > > > >> Say, I have an ATOMIC and TRANSACTIONAL caches in my system, and I > > need > > > to change them at the same time > > > > > > Looks very unreliable. Which guarantees users expect from Ignite in > this > > > case? For example - transaction rollbacks but atomic change (within > this > > > tx) succeeds, and vice versa. I'm not sure Ignite should allow this > > > behaviour. Do you know real real cases when Ignite is used in such a > way? > > > > > > > > > On Tue, Oct 25, 2022 at 3:27 PM Anton Vinogradov <a...@apache.org> > wrote: > > > > > >> >> WDYT? > > >> +1 > > >> > > >> On Tue, Oct 25, 2022 at 11:40 AM Stanislav Lukyanov < > > >> stanlukya...@gmail.com> > > >> wrote: > > >> > > >> > Nikita, > > >> > > > >> > The system property isn't really the problem, right? The problem is > > the > > >> > default behavior? > > >> > Do you suggest that the future behavior change will be added to the > > >> > release notes? > > >> > Can you add a proposed release note text to the ticket so that we > are > > on > > >> > the same page about what will be announced? > > >> > > > >> > Also, should there be something like run-time warning for the > > operations > > >> > that will later become forbidden? > > >> > > > >> > About the 2.16 change. I agree with the default - makes sense. But > can > > >> we > > >> > please keep a way to revert this? > > >> > I think just changing the default behavior but keeping the property > is > > >> the > > >> > best. > > >> > > > >> > The problem is that there can be people that understand the behavior > > but > > >> > want to do that anyway. Say, I have an ATOMIC and TRANSACTIONAL > caches > > >> in > > >> > my system, > > >> > and I need to change them at the same time. How would I do that > after > > >> the > > >> > change is implemented? > > >> > > > >> > > > >> > Thinking about this, I believe a more aggressive change would be > > better > > >> - > > >> > but with a possibility to opt-out. > > >> > My proposal: > > >> > - Don't deprecate the property - revert the commit. > > >> > - Change the default of the property. > > >> > - Make sure the error message explains how to return the old > behavior > > >> > (IGNITE_ALLOW_ATOMIC_OPS_IN_TX=true). > > >> > - Make sure this is mentioned in the release notes. > > >> > - Do this in 2.15, not 2.16. > > >> > > > >> > WDYT? > > >> > > > >> > > > >> > Sorry for diving deep into this - this is a breaking change that > > >> > potentially impacts many users, that's why I'm a bit anxious :) > > >> > > > >> > Thanks, > > >> > Stan > > >> > > > >> > > On 24 Oct 2022, at 21:25, Nikita Amelchev <namelc...@apache.org> > > >> wrote: > > >> > > > > >> > > Stanislav, > > >> > > > > >> > > 2.15: The system property will be deprecated. Release notes will > > >> > > contain warning info about deprecation and behavior in future > > >> > > releases. > > >> > > > > >> > > 2.16: The system property will be removed. All atomic operations > > >> > > within transactions will be forbidden. > > >> > > > > >> > > See merged PR: https://github.com/apache/ignite/pull/10327/files > > >> > > > > >> > > сб, 22 окт. 2022 г. в 17:42, Stanislav Lukyanov < > > >> stanlukya...@gmail.com > > >> > >: > > >> > >> > > >> > >> Hi all, > > >> > >> > > >> > >> Can someone please clarify what specific changes will be > > implemented > > >> in > > >> > 2.15 and 2.16? What will be in release notes in 2.15 and 2.16? > > >> > >> > > >> > >> Thanks, > > >> > >> Stan > > >> > >> > > >> > >>> On 18 Oct 2022, at 21:50, Nikita Amelchev <namelc...@apache.org > > > > >> > wrote: > > >> > >>> > > >> > >>> Hi, Maksim. > > >> > >>> > > >> > >>> I think marking the issue as 'important' and filling out the > > release > > >> > >>> notes field is enough to get the attention of a release manager. > > >> > >>> > > >> > >>> вт, 18 окт. 2022 г. в 20:26, Maksim Timonin < > > >> timoninma...@apache.org>: > > >> > >>>> > > >> > >>>> Hi guys, > > >> > >>>> > > >> > >>>> We agreed here [1] that all deprecations must be noted within > > >> release > > >> > >>>> notes. Do we have an option to mark a jira ticket in such a way > > to > > >> > fill the > > >> > >>>> future release notes correctly? > > >> > >>>> > > >> > >>>> [1] > > >> https://lists.apache.org/thread/3ko0kjdv16o3oftsfh8z8nz0tyfvo13v > > >> > >>>> > > >> > >>>> On Mon, Oct 17, 2022 at 8:21 PM Anton Vinogradov < > a...@apache.org> > > >> > wrote: > > >> > >>>> > > >> > >>>>> Ok, let's do this. > > >> > >>>>> And schedule the fix to the 2.16. > > >> > >>>>> > > >> > >>>>> On Mon, Oct 17, 2022 at 7:42 PM Alexei Scherbakov < > > >> > >>>>> alexey.scherbak...@gmail.com> wrote: > > >> > >>>>> > > >> > >>>>>> By placing the @Deprecated annotation on the property. > > >> > >>>>>> > > >> > >>>>>> пн, 17 окт. 2022 г. в 19:07, Anton Vinogradov <a...@apache.org > >: > > >> > >>>>>> > > >> > >>>>>>> How can we deprecate this? > > >> > >>>>>>> > > >> > >>>>>>> On Mon, Oct 17, 2022 at 5:30 PM Alexei Scherbakov < > > >> > >>>>>>> alexey.scherbak...@gmail.com> wrote: > > >> > >>>>>>> > > >> > >>>>>>>> We can do breaking changes by following the approved > > >> procedure: 1) > > >> > >>>>>>>> deprecate in the next release 2) remove in the some release > > >> after > > >> > the > > >> > >>>>>>> next > > >> > >>>>>>>> > > >> > >>>>>>>> The ticket looks fine to me. > > >> > >>>>>>>> > > >> > >>>>>>>> пн, 17 окт. 2022 г. в 15:50, Anton Vinogradov < > a...@apache.org > > >: > > >> > >>>>>>>> > > >> > >>>>>>>>> We MUST break this, of course! > > >> > >>>>>>>>> Atomic operations inside the transaction is a wrong and > > >> > unexpected > > >> > >>>>>>>>> behaviour and MUST be restricted for every user. > > >> > >>>>>>>>> > > >> > >>>>>>>>> On Mon, Oct 17, 2022 at 3:05 PM Julia Bakulina < > > >> > >>>>>> julia.bak...@yandex.ru > > >> > >>>>>>>> > > >> > >>>>>>>>> wrote: > > >> > >>>>>>>>> > > >> > >>>>>>>>>> Hi Team, > > >> > >>>>>>>>>> > > >> > >>>>>>>>>> I have found this ticket > > >> > >>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-8801 - > > >> > >>>>>>>>>> Change default behaviour of atomic operations inside > > >> > >>>>> transactions - > > >> > >>>>>>> in > > >> > >>>>>>>>>> backlog and created a PR with changes. The ticket relates > > to > > >> > >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-2313. > > >> > >>>>>>>>>> During the review process it appeared that probably there > > is > > >> no > > >> > >>>>>> need > > >> > >>>>>>> in > > >> > >>>>>>>>>> this ticket as it includes the changes of the default API > > >> and we > > >> > >>>>>>> should > > >> > >>>>>>>>> not > > >> > >>>>>>>>>> break backward compatibility. > > >> > >>>>>>>>>> > > >> > >>>>>>>>>> Do we need these changes? Should the ticket be closed > with > > >> > "won't > > >> > >>>>>>> fix"? > > >> > >>>>>>>>>> > > >> > >>>>>>>>>> Have a nice day, > > >> > >>>>>>>>>> Julia > > >> > >>>>>>>>>> > > >> > >>>>>>>>> > > >> > >>>>>>>> > > >> > >>>>>>>> > > >> > >>>>>>>> -- > > >> > >>>>>>>> > > >> > >>>>>>>> Best regards, > > >> > >>>>>>>> Alexei Scherbakov > > >> > >>>>>>>> > > >> > >>>>>>> > > >> > >>>>>> > > >> > >>>>>> > > >> > >>>>>> -- > > >> > >>>>>> > > >> > >>>>>> Best regards, > > >> > >>>>>> Alexei Scherbakov > > >> > >>>>>> > > >> > >>>>> > > >> > >>> > > >> > >>> > > >> > >>> > > >> > >>> -- > > >> > >>> Best wishes, > > >> > >>> Amelchev Nikita > > >> > >> > > >> > > > > >> > > > > >> > > -- > > >> > > Best wishes, > > >> > > Amelchev Nikita > > >> > > > >> > > > >> > > > > > > > > -- > > Best regards, > Alexei Scherbakov >
