The general rule I always have in mind for breaking changes - there should be a way to fallback to the old behavior. Even if the old behavior is unreasonable, and people shouldn't rely on it, you should let them acknowledge they are in the wrong - but continue to operate as they used to.
And in this case, the use case isn't even that crazy - the example Maksim shared is right. To add a bit more color: imagine you have a mobile banking system. The system serves current account balances, and allows to perform actions like requests for payments, transfers, etc. You may want to use Atomic cache to show the current balance for speed (it will be read a lot, and if it's out of sync, it's kind of OK - you can see in banking apps that the current balance is out of sync a lot), but you need to record the actual operations in a Transactional cache of sure. But you'll be making the change in the same business operation, and probably in the same transaction. And if something that you want to cache isn't even user-facing (like account balance on the mobile app) but something internal (like operations counter for rate limiting) this design becomes even more reasonable. Thanks, Stan > On 28 Oct 2022, at 19:12, Maksim Timonin <timoninma...@apache.org> wrote: > > 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 >>
