Remove retries from DML

[Vladimir Ozerov]

Igniters,

Current implementation of DML is not transactional. We have not guarantees
on what is updated and what is not. When certain update fails due to
concurrent entry change, we perform a retry.

The thing is that re-try doesn't guarantee anything still and it might
introduce subtle performance degradation in case of complex queries.

As it has no value for users, I propose to drop it altogether. Semantically
nothing will change from user perspective as we have no guarantees.

Thoughts?

Vladimir.

[dsetrakyan]

Vladimir,

I think non-transactional DML should have the same guarantees as we have in
Atomic caches. Do you agree? If yes, we should discuss DML behavior in
conjunction with Atomic cache behavior.

D.

On Tue, Dec 26, 2017 at 10:44 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> Current implementation of DML is not transactional. We have not guarantees
> on what is updated and what is not. When certain update fails due to
> concurrent entry change, we perform a retry.
>
> The thing is that re-try doesn't guarantee anything still and it might
> introduce subtle performance degradation in case of complex queries.
>
> As it has no value for users, I propose to drop it altogether. Semantically
> nothing will change from user perspective as we have no guarantees.
>
> Thoughts?
>
> Vladimir.
>

[Vladimir Ozerov]

Agree. AFAIK ATOMIC cache doesn't perform retries, does it?

On Wed, Dec 27, 2017 at 12:12 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Vladimir,
>
> I think non-transactional DML should have the same guarantees as we have in
> Atomic caches. Do you agree? If yes, we should discuss DML behavior in
> conjunction with Atomic cache behavior.
>
> D.
>
> On Tue, Dec 26, 2017 at 10:44 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > Current implementation of DML is not transactional. We have not
> guarantees
> > on what is updated and what is not. When certain update fails due to
> > concurrent entry change, we perform a retry.
> >
> > The thing is that re-try doesn't guarantee anything still and it might
> > introduce subtle performance degradation in case of complex queries.
> >
> > As it has no value for users, I propose to drop it altogether.
> Semantically
> > nothing will change from user perspective as we have no guarantees.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>

[dsetrakyan]

On Tue, Dec 26, 2017 at 11:21 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Agree. AFAIK ATOMIC cache doesn't perform retries, does it?
>

I think it does, in some cases. Alexey Goncharuk, can you share some wisdom
here?