问题
Is it appropriate for a server to return 503 ("Service Unavailable")
when the requested operation resulted in a database deadlock?
Here is my reasoning:
- Initially I tried avoiding database deadlocks, but I ran across https://stackoverflow.com/a/112256/14731
- Next, I tried repeating the request on the server-side, but I ran across Java Servlets: How to repeat an HTTP request?. Technically speaking I can buffer the request entity but scalability will suffer and clients are more likely to see
503 Service Unavailable
anyway.
Seeing as:
- It's easier to ask clients to repeat the operation.
- They need to be able to handle
503 Service Unavailable
anyway. - Database deadlocks are rather rare.
I'm leaning towards this solution. What do you think?
UPDATE: I think returning 503 ("Service Unavailable")
is still acceptable if you wish it, but I no longer think it is technically required. See https://stackoverflow.com/a/17960047/14731.
回答1:
I think it's fine so long as the entire transaction is rolled back or if the request is idempotent.
回答2:
I think semantically 409 Conflict is a better alternative - basically if you have a deadlock there's contention for some resource, and so the operation could not be completed.
Now depending on the reason for the deadlock, the request may not succeed if submitted a second time, but that's true for anything.
For a 503, as a client I'd implement some sort of back-away/circuit breaker operation as the system is rate limited, whereas 409 relates to the specific request.
来源:https://stackoverflow.com/questions/16628713/is-it-appropriate-to-return-http-503-in-response-to-a-database-deadlock