> 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

> 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