4 ms·

It is guaranteed to return after either inserting or updating. Most implementors terminate the loop after some arbitrary number because an error elsewhere could

It is guaranteed to return after either inserting or updating. Most implementors terminate the loop after some arbitrary number because an error elsewhere could prevent both insertion and deletion, and it is nice to get an exception rather than a hang in from your upsert.

the_mitsuhiko 13y ago
> It is guaranteed to return after either inserting or updating. Most implementors terminate the loop after some arbitrary number because an error elsewhere could prevent both insertion and deletion, and it is nice to get an exception rather than a hang in from your upsert. Which is why I said multiple times that this needs database support at which point a lock. That would guarantee that the contention at the lock is fair. With a loop around that section the winner is chosen by network latency and retry speed if high contention happens. Also there is not even a guarantee that it will ever finish.
- amirouche 13y ago
  > Which is why I said multiple times First time read that... > that this needs database support Transaction retry is part of mvcc databases > at which point a lock. Not necessarily. > That would guarantee that the contention at the lock is fair. It's not fair, it's a lock. Locking all the table for one row, is not fair. I don't know what you mean by fair. > With a loop around that section the winner is chosen by network latency and retry speed if high contention happens. Yes and? Anyway, this must be in the database, the database knows the transaction can pass, it doesn't need to send it back to the user, except if there is heavy writes on this row, which would mean the application is under attack or not correctly programmed. > Also there is not even a guarantee that it will ever finish. There is a MAX_RETRY, it is guaranteed to return. --- Also: - You don't state your problem upfront, just say you need this COMMAND. Which is forbidden by netiquette. - You never state that it's a Write/Write transaction problem - What about Read/Write? - There is a solution, use a migration or MYSQL

the_mitsuhiko 13y ago

> It is guaranteed to return after either inserting or updating. Most implementors terminate the loop after some arbitrary number because an error elsewhere could prevent both insertion and deletion, and it is nice to get an exception rather than a hang in from your upsert. Which is why I said multiple times that this needs database support at which point a lock. That would guarantee that the contention at the lock is fair. With a loop around that section the winner is chosen by network latency and retry speed if high contention happens. Also there is not even a guarantee that it will ever finish.

amirouche 13y ago
> Which is why I said multiple times First time read that... > that this needs database support Transaction retry is part of mvcc databases > at which point a lock. Not necessarily. > That would guarantee that the contention at the lock is fair. It's not fair, it's a lock. Locking all the table for one row, is not fair. I don't know what you mean by fair. > With a loop around that section the winner is chosen by network latency and retry speed if high contention happens. Yes and? Anyway, this must be in the database, the database knows the transaction can pass, it doesn't need to send it back to the user, except if there is heavy writes on this row, which would mean the application is under attack or not correctly programmed. > Also there is not even a guarantee that it will ever finish. There is a MAX_RETRY, it is guaranteed to return. --- Also: - You don't state your problem upfront, just say you need this COMMAND. Which is forbidden by netiquette. - You never state that it's a Write/Write transaction problem - What about Read/Write? - There is a solution, use a migration or MYSQL