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

Question

Is it appropriate for the server to return 503 ("Service Unavailable") when the requested operation resulted in a database lock?

Here are my thoughts:

• At first, I tried to avoid database locks, but I stumbled upon https://stackoverflow.com/a/167354/ ...
• Then I tried to repeat the request on the server side, but I came across Java Servlets: how to repeat the HTTP request? . From a technical point of view, I can buffer the request object, but scalability will suffer, and clients are more likely to see 503 Service Unavailable anyway.

See how:

• It’s easier to ask customers to repeat the operation.
• In any case, they should be able to handle 503 Service Unavailable .
• Database deadlocks are quite rare.

I am inclined to this decision. What do you think?

UPDATE . I think returning 503 ("Service Unavailable") is still acceptable if you want to, but I no longer think it is technically necessary. See https://stackoverflow.com/a/166778/

Answer 1

I think this is normal while the whole transaction is rolled back or if the request is idempotent.

Answer 2

I think that semantically 409 Conflict is the best alternative - basically, if you have a dead end, there is competition for some resource, and therefore the operation cannot be completed.

Now, depending on the cause of the deadlock, the request may fail if it is submitted a second time, but this is true for everything.

For 503, as a client, I would perform some kind of retraction / shutdown operation, since the system is limited in speed, while 409 refers to a specific request.