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