Concurrent Transaction control in MonetDB

Sjoerd Mullender sjoerd at monetdb.org
Mon Oct 19 10:22:06 CEST 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 <sjoerd at monetdb.org
> <mailto:sjoerd at 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 at monetdb.org <mailto:developers-list at monetdb.org>
>     > https://www.monetdb.org/mailman/listinfo/developers-list
>     >
> 
>     --
>     Sjoerd Mullender
> 
> 
>     _______________________________________________
>     developers-list mailing list
>     developers-list at monetdb.org <mailto:developers-list at monetdb.org>
>     https://www.monetdb.org/mailman/listinfo/developers-list
> 
> 
> 
> 
> _______________________________________________
> developers-list mailing list
> developers-list at monetdb.org
> https://www.monetdb.org/mailman/listinfo/developers-list
> 


-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://www.monetdb.org/pipermail/developers-list/attachments/20151019/4aa5f4c2/attachment.sig>


More information about the developers-list mailing list