Updates reordering in transaction with cache store

[Valentin Kulichenko]

Igniters,

Imagine the following scenario:

startTx {
    cache.get("key2");

    cache.put("key1", val1);
    cache.put("key2", val2);

    commit();
}

In the transaction above key1 is updated first, and then key2. But since we
access key2 at the very beginning, cache store is updated in different
order (key2, than key1).

While I understand that this happens for a reason, this is actually a
serious usability issue, because in many cases user will have constraint
violation because of this.

Is there a way to fix this? My idea is to track updates for the store in a
separate linked structure, so that get operations do not affect it. Will
this work? If there are no objections, I will create a ticket.

-Val

[yzhdanov]

Val, actually there is no reordering. It seems you use pessimistic
repeatable read transaction and entries are flushed into DB in the same
order entries are locked in memory.

You can do:
1. Lock all the keys in the same order, i.e. add cache.get("key1");
2. switch to non-repeatable read transactions

--Yakov

[Valentin Kulichenko]

Yakov,

I understand all that, but I think there is still a usability issue. Order
of updates in a transactional persistent store can be very important due to
constraints. And currently this order is unpredictable, counterintuitive
and uncontrollable from user's point of view.

I create a transaction with two updates and get store updates in some
order. I then add get() operation before these updates (which likely
doesn't touch store, btw), store is updated in different order. I change
transaction mode, order changes again. WTF? :)

Is it possible to track updates in separate map in transaction and then use
it during cache store commit? Will this work? Can this break anything
and/or affect performance in negative way?

-Val

On Wed, Jan 25, 2017 at 2:00 AM, Yakov Zhdanov <[hidden email]> wrote:

> Val, actually there is no reordering. It seems you use pessimistic
> repeatable read transaction and entries are flushed into DB in the same
> order entries are locked in memory.
>
> You can do:
> 1. Lock all the keys in the same order, i.e. add cache.get("key1");
> 2. switch to non-repeatable read transactions
>
> --Yakov
>

[yzhdanov]

Val, order is predictable - this is the order of update operations. You can
do get() to lock all the keys in the order your DB is OK with.

I can't say if new structure will affect performance or not, but it
definitely can do so.

--Yakov

2017-01-26 8:10 GMT+03:00 Valentin Kulichenko <[hidden email]
>:

> Yakov,
>
> I understand all that, but I think there is still a usability issue. Order
> of updates in a transactional persistent store can be very important due to
> constraints. And currently this order is unpredictable, counterintuitive
> and uncontrollable from user's point of view.
>
> I create a transaction with two updates and get store updates in some
> order. I then add get() operation before these updates (which likely
> doesn't touch store, btw), store is updated in different order. I change
> transaction mode, order changes again. WTF? :)
>
> Is it possible to track updates in separate map in transaction and then use
> it during cache store commit? Will this work? Can this break anything
> and/or affect performance in negative way?
>
> -Val
>
> On Wed, Jan 25, 2017 at 2:00 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Val, actually there is no reordering. It seems you use pessimistic
> > repeatable read transaction and entries are flushed into DB in the same
> > order entries are locked in memory.
> >
> > You can do:
> > 1. Lock all the keys in the same order, i.e. add cache.get("key1");
> > 2. switch to non-repeatable read transactions
> >
> > --Yakov
> >
>

[Alexey Goncharuk]

Generally I agree with Yakov here, now order of updates is fully consistent
with the order of cache locks acquisition. You change the transaction type
=> you change the order of cache locks => you change the order of db writes.

I can assume that in some cases such a reordering may be useful, however we
are not allowed to change this behavior by default (it will break existing
Ignite deployments), which leads to yet another configuration property.
Given that *there is* a predictable order of db updates, I would not add
this feature.

2017-01-26 8:10 GMT+03:00 Valentin Kulichenko <[hidden email]
>:

> Yakov,
>
> I understand all that, but I think there is still a usability issue. Order
> of updates in a transactional persistent store can be very important due to
> constraints. And currently this order is unpredictable, counterintuitive
> and uncontrollable from user's point of view.
>
> I create a transaction with two updates and get store updates in some
> order. I then add get() operation before these updates (which likely
> doesn't touch store, btw), store is updated in different order. I change
> transaction mode, order changes again. WTF? :)
>
> Is it possible to track updates in separate map in transaction and then use
> it during cache store commit? Will this work? Can this break anything
> and/or affect performance in negative way?
>
> -Val
>
> On Wed, Jan 25, 2017 at 2:00 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Val, actually there is no reordering. It seems you use pessimistic
> > repeatable read transaction and entries are flushed into DB in the same
> > order entries are locked in memory.
> >
> > You can do:
> > 1. Lock all the keys in the same order, i.e. add cache.get("key1");
> > 2. switch to non-repeatable read transactions
> >
> > --Yakov
> >
>