4 ms·

"Asking to redo the transaction" pushes complexity into the client. Armin did mention that: "Unfortunately this problem does not go away if you tell the client

by ash 13y ago

"Asking to redo the transaction" pushes complexity into the client. Armin did mention that: "Unfortunately this problem does not go away if you tell the client to solve it."

amirouche 13y ago
Asking to redo the transaction doesn't mean "push the error to client". In this case, server knows the transaction can pass, so you don't push the error to the client. The server push errors to the client when: - it is sure that the transaction can not pass. - it doesn't want to guess whether the transaction can pass. - it reached a max retry (because of heavy writes for instance)
- the_mitsuhiko 13y ago
  What you are suggesting is a loop where you try update/insert until it succeeds. Because there is no lock involved there is no guarantee that it will ever finish. That's exactly what's being mentioned in the blog as a workaround until an upsert exists.
  - deleted 13y ago
    [deleted]
  - spacemanmatt 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.
    - 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

by ash 13y ago

"Asking to redo the transaction" pushes complexity into the client. Armin did mention that: "Unfortunately this problem does not go away if you tell the client to solve it."

amirouche 13y ago

Asking to redo the transaction doesn't mean "push the error to client". In this case, server knows the transaction can pass, so you don't push the error to the client. The server push errors to the client when: - it is sure that the transaction can not pass. - it doesn't want to guess whether the transaction can pass. - it reached a max retry (because of heavy writes for instance)

the_mitsuhiko 13y ago
What you are suggesting is a loop where you try update/insert until it succeeds. Because there is no lock involved there is no guarantee that it will ever finish. That's exactly what's being mentioned in the blog as a workaround until an upsert exists.
- deleted 13y ago
  [deleted]
- spacemanmatt 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.
  - 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