is starvation possible here? E.g. there are two nodes with GUIDs A and B. What will happen in the following case: 1) TX (A, 1) started and locked the key; 2) TX (B, 1) started and waiting for lock; 3) TX (A, 2) started and waiting for lock; 4) TX (A, 1) released the lock. 5) Who wins now? If this is (A, 2), then lock acquisition by the node B can be postponed indefinitely.
On Thu, Oct 15, 2015 at 11:18 AM, Alexey Kuznetsov <akuznet...@gridgain.com> wrote: > Just one more question: > > "- transaction with greater order should always 'win' transaction with > lower order" > > Greater order means "younger"? > > If it so, why should younger transactions win? Why not older? > > Or user will have possibility to configure this aspect of conflict > resolution? > > On Thu, Oct 15, 2015 at 3:07 PM, Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > 2015-10-15 10:58 GMT+03:00 Alexey Kuznetsov <akuznet...@gridgain.com>: > > > > > > Also it is not clear for me, how transaction order is assigned / > > > calculated? > > > If I start transaction t1 on none n1 and t2 on node n2, how it will be > > > calculated? > > > > > I believe that we can utilize nearXidVersion for this ordering (or some > > sort of it's modification). Since cache version contains local order, > > topology version and node ID and also is comparable, it is guaranteed > that > > nearXidVersion is always unique and there is always an unambiguous order > > between any two Xid versions. > > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
