Concurrent Transaction control in MonetDB
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.
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
Thanks for the clarifications.
If so, then there is a minor probability that if 2 concurrent requests are trying to update a column in a row, then even a genuine latest request would simply be ignored and the data will be having the older request only.
Am I getting this right?
Thanks & Regards,
Vijayakrishna.P. Mobile : (+91) 9500402305.
On Sun, Oct 18, 2015 at 2:24 PM, Sjoerd Mullender sjoerd@monetdb.org wrote:
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
developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
On 19/10/15 08:26, Vijay Krishna wrote:
Thanks for the clarifications.
If so, then there is a minor probability that if 2 concurrent requests are trying to update a column in a row, then even a genuine latest request would simply be ignored and the data will be having the older request only.
Am I getting this right?
If the second transaction starts before the first is committed, then yes, it will be aborted. But aborting it means that the transaction fails, and you will be notified of that when you try to commit. If the second transactions starts after the first is committed, it should go through.
Thanks & Regards,
Vijayakrishna.P. Mobile : (+91) 9500402305.
On Sun, Oct 18, 2015 at 2:24 PM, Sjoerd Mullender <sjoerd@monetdb.org mailto:sjoerd@monetdb.org> wrote:
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 <mailto:developers-list@monetdb.org> > https://www.monetdb.org/mailman/listinfo/developers-list > -- Sjoerd Mullender _______________________________________________ developers-list mailing list developers-list@monetdb.org <mailto:developers-list@monetdb.org> https://www.monetdb.org/mailman/listinfo/developers-list
developers-list mailing list developers-list@monetdb.org https://www.monetdb.org/mailman/listinfo/developers-list
participants (2)
-
Sjoerd Mullender -
Vijay Krishna