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