乐观锁定重试:它应该由客户端还是服务器处理?

时间:2015-12-02 02:57:14

标签: multithreading concurrency optimistic-locking optimistic-concurrency

我已经构建了一个安静的java spring mongodb数据框架。目前,如果我的后端遇到OptimisticLockingFailureException,我只是向我的ios客户端返回一个错误,它只会告诉用户手动重试。我希望通过让系统在看到此OptimisticLockingFailureException时重试自动来实现自动化。但我想知道是否应该捕获此异常并仅在我的后端重试,或者我是否仍然会返回错误,而是让客户端在看到此类异常时重试发送请求?

感谢您的帮助!

1 个答案:

答案 0 :(得分:0)

除非您仍然需要以某种方式让用户参与其中,否则我无法想到在客户端进行重试的任何优势。

在服务器端重试的优点是:重试可以更快地执行,在更好的受控环境中发生(排除WAN问题),有更多错误上下文(确切地知道它OptimisticLockingFailureException - 在下一个更多内容段落),使用更少的流量,更少的请求解析和上下文构造,将使服务更容易访问和更容易使用客户端,将对所有可能的客户端做好以后可能写(android,js,iOS客户端重写,卷曲等。 ),可以透明地添加到最初不使用DB的操作,以及更多......

但是,如果您决定在客户端上处理问题,我认为让客户端知道确切问题的原因是错误的,因为它是一个实现细节。毕竟,您可能稍后切换到具有不同异常的另一个DB。相反,我认为支持具有合适语义的更一般的机制,例如,返回HTTP代码503并设置"Retry-After"标头(请参阅HTTP statuscode to retry same request)。 指定您的API客户端可能/应该期望并处理此组合(并在iOS客户端中处理)可能是明智之举:那么可能是立即或者也许以后你可以转发你的客户端在服务器端执行重试并在OptimisticLockingFailureException发生时停止返回代码503(如果你想限制请求率并且你的客户已经处理它,可能会开始返回它)。推迟此决定并允许以某种方式重播它将使您在API中获得更多自由。