【问题标题】:Transaction sharing in PostgresqlPostgresql 中的事务共享
【发布时间】:2014-01-05 14:46:11
【问题描述】:

是否可以使用 Postgres 在多个进程之间重用相同的事务?或任何其他 RDBMS?这种概念有名称吗?是否有意义?

一个可能的用例是两个服务实例(不同的进程)在一个分布式事务中修改相关的一组实体。

例如,想象一个显示音乐播放列表的网站。普通用户可以看到播放列表,但编辑者可以协作编辑播放列表。编辑者会修改列表,但在其中一位编辑者保存(提交)更改之前,查看者不会看到最新的更改。

这只是说明性示例,将采用不同的设计方法,而不依赖于分布式事务。我只是对分布式事务的概念及其合理性感兴趣,因为我不是该领域的专家。

【问题讨论】:

标签: postgresql transactions


【解决方案1】:

我认为拥有一个进程、方法或服务来询问两个后端服务以获取必要的信息,然后在事务本身中执行操作更有意义。

也就是说,您可能正在寻找Two-Phase Commit。请注意该页面上关于让提交打开时间过长的警告。

【讨论】:

  • 我同意,但我很好奇交易共享的可能性。我只是在设计中考虑不同的选项,所以知道这样的事情是可能的将使一些元素更容易理解和使用。
  • 其实,如果你能为此提供一个功能场景,我可能会制定一个更好的答案。
  • 我添加了一个例子,但问题更多是理论上的,所以请不要想当然。
  • 这不是数据库意义上的事务。它更像是一个“门”。您将有一个版主批准表来发布更改,和/或播放列表表上的版主 ID,您可以将其设置为批准它的版主的 ID。然后,您的查询中将有一个 WHERE 子句,该子句仅捕获经版主批准的记录。
  • 我应该找到一个更好的例子,但它只是说明了这个想法,而不是实际的设计问题。我理解并欣赏您提出的设计,但这并不是我提出问题的目的。
猜你喜欢
  • 1970-01-01
  • 2010-11-02
  • 1970-01-01
  • 2020-02-14
  • 1970-01-01
  • 2021-09-12
  • 2012-10-23
  • 2013-02-04
  • 2021-05-25
相关资源
最近更新 更多