ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Updates reordering in transaction with cache store
Date Thu, 26 Jan 2017 09:29:18 GMT
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.kulichenko@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 <yzhdanov@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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message