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 |
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 |
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 > |
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 > > > |
In reply to this post by Valentin Kulichenko
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 > > > |
Free forum by Nabble | Edit this page |