Re: Conflict Detection and Resolution

On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> > I doubt that it would be that simple. The application will have to
> intervene and tell one of the employees that their reservation has failed.
> It looks natural that the first one to reserve the room should get the
> reservation, but implementing that is more complex than resolving a
> conflict in the database. In fact, mostly it will be handled outside
> database.
> >
>
> Sure, the application needs some handling but I have tried to explain
> with a simple way that comes to my mind and how it can be realized
> with db involved. This is a known conflict detection method but note
> that I am not insisting to have "earliest_timestamp_wins". Even, if we
> want this we can have a separate discussion on this and add it later.
>
>
It will be good to add a minimal set of conflict resolution strategies to
begin with, while designing the feature for extensibility. I imagine the
first version might just detect the conflict and throw error or do nothing.
That's already two simple conflict resolution strategies with minimal
efforts. We can add more complicated ones incrementally.

> >
> > The inconsistency will arise irrespective of conflict resolution method.
> On a single system effects of whichever transaction runs last will be
> visible entirely. But in the example above the node where T1, T2, and T3
> (from *different*) origins) are applied, we might end up with a situation
> where some changes from T1 are applied whereas some changes from T3 are
> applied.
> >
>
> I still think it will lead to the same result if all three T1, T2, T3
> happen on the same node in the same order as you mentioned. Say, we
> have a pre-existing table with rows r1, r2, r3, r4. Now, if we use the
> order of transactions to be applied on the same node based on t2 < t1
> < t3. First T2 will be applied, so for now, r1 is a pre-existing
> version and r2 is from T2. Next, when T1 is performed, both r1 and r2
> are from T1. Lastly, when T3 is applied, r1 will be from T3 and r2
> will be from T1. This is what you mentioned will happen after conflict
> resolution in the above example.
>
>
You are right. It won't affect the consistency. The contents of transaction
on each node might vary after application depending upon the changes that
conflict resolver makes; but the end result will be the same.

--
Best Wishes,
Ashutosh Bapat