Re: Concurrent Transaction control in MonetDB

19 Oct 2015


      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 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
    > 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 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
-- 
Sjoerd Mullender