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 <[email protected]> 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 >
