Is it appropriate to return HTTP 503 in response to a database deadlock?

Question

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://mcmap.net/q/282425/-zero-sql-deadlock-by-design-any-coding-patterns
• 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://mcmap.net/q/1627209/-java-servlets-how-to-repeat-an-http-request.

Apocynthion

Even if you program this in production you may still end up with timeout, which would cause your load balancing proxy to send 504 to client. – Longfellow

@agilevic, what do you mean? Are you saying I need to ensure deadlock-by-timeout is configured to use a small timeout value to avoid HTTP 504? – Apocynthion

Database deadlocks can last longer than load balancer's timeout thus blocking the response. If you are capable of detecting a deadlock before that timeout you can respond to client with 503 - a sensible choice. – Longfellow

Answer 1

I think it's fine so long as the entire transaction is rolled back or if the request is idempotent.

Charis

Answer 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.

Farrell

Answer 3

Just got here with the same question and no clear answer on the issue.

• a 503 is acceptable but might not be correctly interpreted
• a 409 is also OK but in my case was not OK (since multiple resources could end up returning a this error for the same URL)

In my case I ended up returning a 307 redirect on the same URL.

Clients will automatically "retry" and the second call works because the resource is only raising a deadlock during its initial creation.

Be warned that might end up in an infinite loop

Graeco