我的应用程序应该如何处理安全处理的数据库冲突？

Question

• 我的应用程序使用错误报告来跟踪异常。
• 我的应用程序使用SQL事务来确保操作完全完成或根本不完成。
• 我的应用程序是多线程的。
• 当超过一个事务试图做相同的事情时，就会出现异常。这是好的，因为他们中只有一个应该成功。
• 当发生碰撞时，会引发并报告异常。
• 调查异常需要时间。

我的应用程序应该如何处理这样的“安全”异常？

备注：

• 可能很难区分“安全”和“不安全”异常，因为引发的异常来自数据库模块，消息可能是泛型的。
• 由“安全”冲突引起的异常可能有不同的错误消息，这取决于错误发生在事务中的哪个点。

Answer 1

根据应用程序的类型，有时取决于特定的事务，您需要选择以下选项之一：

1. 第一个更改获胜(第二个事务是回滚的)。
2. 第二个更改获胜(不管异常如何，第二个事务都是执行的，该异常可能仅用于日志记录)。
3. 用户(通常是发起第二次更改的用户)需要交互地决定这两项更改中的哪一项将获胜。
4. 我们可以找到一个解决方案，系统可以根据具体情况自动决定#1和#2。

对于#3，用户可能需要查看这两个更改的数据才能做出合格的决定，因此这可以成为相当大的努力来实现。在某些应用程序中，向用户提供将两个更改的部分合并为一个组合部分的选项(例如，Wikipedia提供了这样一个模型，当两个用户同时编辑同一篇文章时)。

不幸的是，没有一刀切的解决方案，你需要详细分析需求，然后选择你选择的折衷方案。

Answer 2

我的应用程序使用错误报告来跟踪异常。

通过阅读这篇文章，我建议你似乎对“异常”有了自己的定义。

..。SQL事务..。操作已完全完成或根本没有完成。

所以你有原子事务。好的。

我的应用程序是多线程的

这不是问题，因为您有原子事务。

当超过一个事务试图做相同的事情时，就会出现异常.他们中只有一人会成功。当发生碰撞时，会引发异常，而reported.调查异常需要时间。

我把报告例外看作是一种“最后的手段”。

对于捕获代码来说，对异常做一些事情要好得多，这样在理想情况下，当捕获代码完成时，就好像没有发生异常一样。但是，在数据库事务的情况下，这可能不实用，因为根据定义，数据“景观”将在您第一次尝试之后发生变化(被另一个事务破坏了，因为它成功了)。让用户选择再试一次是更可行的。

大多数由数据访问框架引发的异常将包含(具有讽刺意味的)某种错误号/代码或"sql状态“。它很可能因DBMS而异，但您应该能够查询这些属性，以确定异常是“安全的”异常还是真正的“坏”异常。