响应数据库死锁返回HTTP 503合适吗？

Question

当请求的操作导致数据库死锁时，服务器返回503 ("Service Unavailable")是否合适？

以下是我的推理：

• 一开始我试图避免数据库死锁，但我遇到了https://stackoverflow.com/a/112256/14731
• 接下来，我尝试在服务器端重复请求，但是我遇到了Java Servlets: How to repeat an HTTP request?。从技术上讲，我可以缓冲请求实体，但是可伸缩性会受到影响，而且客户机更有可能看到503 Service Unavailable。

视为：

• 更容易让客户重复操作。
• 无论如何，他们需要能够处理503 Service Unavailable。
• 数据库死锁相当罕见。

我倾向于这个解决方案。你认为如何？

UPDATE：如果您愿意，我认为返回503 ("Service Unavailable")仍然是可以接受的，但我认为它在技术上不再是必需的。见https://stackoverflow.com/a/17960047/14731。

Answer 1

我认为只要整个事务被回滚，或者请求是幂等的，就可以了。

Answer 2

我认为语义409冲突是一个更好的选择--基本上，如果您有一个死锁，就会有一些资源争用，因此操作无法完成。

现在，根据死锁的原因，如果第二次提交请求，请求可能不会成功，但对于任何情况都是如此。

对于503，作为一个客户端，我会实现某种后退/断路器操作，因为系统的速率是有限的，而409涉及到特定的请求。

Answer 3

我只是带着同样的问题来到这里，在这个问题上没有明确的答案。

• A 503是可以接受的，但可能无法正确解释。
• 409也可以，但在我的例子中不是OK (因为多个资源最终可能返回同一个URL的这个错误)

在我的例子中，我最终在同一个URL上返回了307重定向。

客户端将自动“重试”，而第二次调用可以工作，因为资源在最初创建时只会引发死锁。

请注意，可能会以无限循环结束。