Exclude append-increments from tx changeset
Description
Release Notes
is blocked by
relates to
Activity

Alex Baranau July 28, 2015 at 9:07 PM
as per comment & disccusion - there's nothing to do here

Sreevatsan Raman July 23, 2015 at 9:33 PM
I see the status is in in progress? Which release are we targeting this?

Alex Baranau June 17, 2015 at 11:56 PM
We need first make NONE conflict level truly available for usage before documenting how it can be used with append increments

Alex Baranau May 29, 2015 at 1:08 AM
Heh. It looks like it may not be good idea to remove increments from conflict detection. The level of conflict detection that we provide is "if two concurrent tx modified the same item only one will succeed". App logic may rely on this to e.g. make sure some invariant remains after ops are performed: e.g. account balance will not go over the credit limit. If app logic does withdraw using "readless increments" it expects that the invariant will not be broken as the logic checks the number and then does increment.
So, we can't actually exclude increments from tx conflict detection without changing the guarantees we provide (level of conflict detection). Instead, what we can say is you can safely use ConflictLevel.NONE with readless increments - it will not cause an error in counting (even if same counter is changed by two concurrent transactions).
I'll think more and this will probably result in docs change.
Details
Details
Assignee

Reporter

Seems like we still include append (readless) increments into tx changeset that we use to detect conflicts, as we build it based on table's buffer keys. We should not do that - append increments never cause conflicts.
Should be easy to do - exclude those based on Update type