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 <valentin.kuliche...@gmail.com
>:
> 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 <yzhda...@apache.org>
> 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
> >
>
