The first transaction that actually attempts to commit wins.  You can't
wait for the last concurrent transaction, because it might not commit at
all and then nobody can commit.  This would also be a recipe for a
denial of service attack.
Reasons it might not commit are, it does a rollback, it is a badly
written application that never terminates, or either the application or
the server crashes.

On 10/18/2015 08:01 AM, Vijay Krishna wrote:
> Hi,
>
> I read the following lines in a thesis on MonetDB titled - "Improving
> Transactional Stability in MonetDB" where in they had explained the
> concurrency control in MonetDB as
>
> "Concurrent updates (writers) are not anticipated and in case of N
> con􏰃icting transactions, only one of them (the one having the earliest
> time-stamp) is guaranteed to eventually commit its changes.
> Concurrent appends (on the same table) are detected as write-to-write
> conflicts and only the writer carrying the earliest time-stamp will end
> up committing successfully, the rest will be aborted."
>
> Why is that the transaction having the earliest timestamp is allowed to
> commit, in case of a conflict?
> Shouldn't it be the latest transaction that should commit on a data,
> since the latest transaction would be having the latest version of data?
>
> Or, what am I getting wrong here? Any help much appreciated.
>
>
> Thanks & Regards,
>
> Vijayakrishna.P.
> Mobile : (+91) 9500402305.
>
>

> _______________________________________________
> developers-list mailing list
> developers-list@monetdb.org
> https://www.monetdb.org/mailman/listinfo/developers-list
>

--
Sjoerd Mullender


_______________________________________________
developers-list mailing list
developers-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/developers-list