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 <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
> >
>
