手动同步数据库操作并避免内置数据库同步机制是否明智？答案

【问题标题】：Is it wise to manually synchronize database operations and avoiding the inbuilt database synchronization mechanism?手动同步数据库操作并避免内置数据库同步机制是否明智？
【发布时间】：2020-05-31 04:49:20
【问题描述】：

我正在制作这个应用程序，它可以从数据库读取和写入数据，并且可以被多个用户访问。为了避免并发问题，我使用互斥锁。我使用的数据库是 postgresql。它的文档说它符合 ACID 并提供各种级别的同步，例如 read_committed 等。所以我可以避免使用互斥锁并将我的所有语句放在一个事务块中，数据库会处理它。但我对使用这种基于事务的方法并不完全有信心，因为我对数据库自动机制存在信任问题。

我目前的做法：

mutex.lock();
\\perform database operations
mutex.unlock();

替代方法：

begin transaction
\\perform database operations
end transaction

使用互斥体处理是否明智，还是应该依赖数据库机制。每个用户都在一个单独的线程中访问数据库。并且数据库操作很简单。一读一写。就是这样。

【问题讨论】：

Mutex 是应用程序级别，而不是数据库级别。它不保证多个进程中的多个 DB 语句 之间的有效 DB 原子性（或者如果没有一致使用）。根据需要使用 DB 事务 进行有效操作。 RDBMS 锁和升级已经很好地开发了。应用程序还可以执行自己的锁定和防护；它应该是次要性质，而不是取代正确的数据库用法。
原子性我正在通过 try 和 catch 语句来处理。
再读一遍，了解互斥锁的基本限制以及为什么不能用此类替换数据库级事务。
（但是，嘿，做你想做的事。在征求意见后，不要费心听取那些每天在复杂环境中编写此类代码的人的建议......我们中的许多人已经克服了任何“信任”问题”与关系数据库在策划理解后。）

标签： database synchronisation

【解决方案1】：

如果多个用户同时访问数据库，应用程序级别的互斥锁绝对不会阻止他们在数据库端互相踩踏¹。您必须使用在数据库级别（事务）提供的锁定结构来实现您所追求的。

应用程序级互斥锁的更好用例是在应用程序内运行的线程之间提供资源锁定（这也可以通过数据库事务实现，但使用正确的工具来完成这项工作）。

_{1：在这里我必须小心：如果应用程序在单个实例中处理多个用户，或者以其他方式在数据库之外共享数据库对象，那么互斥锁可能是进行锁定的好方法。即便如此，它也不会保护数据库上的东西（这意味着它不是内置在 DBMS 中的功能），让数据库处理它自己的锁可能会更好。子>}

【讨论】：

由于我使用互斥锁，多个用户如何同时访问？通过应用程序（JDBC 代码）访问数据库。
多个用户是否都通过应用程序的单个实例访问数据库？这是互斥锁会有所帮助的唯一情况，但即使在这种情况下，您最好让数据库处理它自己的锁定，而不是尝试在应用程序中重新创建它。
信不信由你，许多应用程序与许多进程（和/或服务器/容器）一起运行，或者以其他方式共享公共数据库工件，即使它们是“不同的”应用程序。
@user2864740 比较这些结构时可能实现的异同将取决于perform database operations 的含义。但总的来说，除非您知道您需要一个互斥锁，否则让数据库处理锁定可能是更安全的选择。
@Z4-tier 我同意^_^