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
