这种互斥实现在PostgreSQL中有意义吗？

我需要在PostgreSQL中实现数据库会话之间的同步

在SQL Server中，我将通过创建自己的“锁定”表来实现它

我不使用显式事务来避免真正的锁定，我将通过将会话Id设置为“所有者”来获得我的“单例”锁

通过不使用显式事务，我不会阻碍其他进程。 您可以将其视为“软锁”

如果我的更新成功，那么我知道我“拥有”了锁，我可以在其他人等待的时候处理一些代码。 如果我的更新没有更新，我知道其他人有“锁”，我会等待，或者放弃

我需要在PostgreSQL中实现类似的东西

---

你会这样做吗？

不，我会换一种方式做

问题是您需要继续轮询锁，这意味着不必要地浪费了CPU时间或比必要的等待时间更长

此要求适用于PostgreSQL：

选择一个锁号，而不是像

Singleton

这样的锁名，例如1234

要获得锁，请运行

SELECT pg_advisory_lock(1234);

SELECT pg_advisory_unlock(1234);

要释放锁，请运行

SELECT pg_advisory_lock(1234);

SELECT pg_advisory_unlock(1234);

这与普通数据库锁的工作原理相同，如果锁不可用，则暂停调用过程，并在锁持有者释放锁后立即恢复调用过程。还有一些功能可以在不阻塞的情况下“轮询”可用性的建议锁

这些锁独立于PostgreSQL的事务，它们一直保持到释放或数据库会话结束（因此不存在“孤立锁”的危险）

这些锁也不会干扰自动真空操作

---

如果应用程序希望使用数据库技术进行同步，这是一个完美的工具。

如果“客户端”软件执行某种连接池，如果我们不明确释放会话通知锁，我们是否有可能无意中传递它们？是，它们与会话相关联。在这种情况下，如何处理客户端崩溃？在我的例子中，我有一个JDBC连接池，当客户端崩溃时，连接只是返回到池中，因此不会关闭会话，也不会释放锁。连接池通常在每个连接返回到池中时发送“cleanup”语句。我想这取决于您使用的应用服务器，它不是JDBC的一部分。我也不知道细节。