【问题标题】:Python async transactions psycopg2Python 异步事务 psycopg2
【发布时间】:2016-08-03 11:56:49
【问题描述】:

可以使用 psycopg2(可以是 read here)进行异步 i/o,但是我不确定如何进行异步事务。考虑一下这一系列的事情:

  • 绿色线程 1 启动事务 T
  • GT1 问题更新
  • GT2 发布一个事务性更新
  • GT1 问题更新
  • GT1 提交事务 T

我假设 GT1 更新与 GT2 更新冲突。

现在根据docs

从同一连接创建的游标不是孤立的,即任何 游标对数据库所做的更改立即可见 其他光标。

所以我们不能在游标上实现上面的流程。我们可以在不同的连接上实现它,但由于我们正在执行异步操作,因此产生(可能)数千个数据库连接可能很糟糕(更不用说 Postgres 无法处理这么多开箱即用的问题)。

另一种选择是拥有一个连接池并重用它们。但是,如果我们发出 X 个并行事务,则所有其他绿色线程都会被阻塞,直到某个连接可用。因此,实际可用的绿色线程数量为 ~X(假设应用程序受数据库限制严重),这引发了一个问题:我们为什么要使用 async 开始?

现在这个问题实际上可以推广到 DB API 2.0。也许真正的答案是 DB API 2.0 不适合异步编程?那么我们将如何在 Postgresql 上执行异步 io 呢?也许其他一些图书馆?

或者可能是因为 postgresql 协议实际上是同步的?能够在任何时间(每个连接)“写入”任何事务将是完美的。 Postgresql 必须为此公开事务的 id。可行吗?也许两阶段提交就是答案?

或者我在这里遗漏了什么?

编辑:这似乎是 SQL 的一个普遍问题,因为 BEGIN; COMMIT; 语义不能有效地异步使用。

【问题讨论】:

标签: python postgresql asynchronous psycopg2 python-db-api


【解决方案1】:

其实你可以使用BEGIN;和承诺;与异步。您需要的是一个连接池设置,并确保每个绿色线程都有自己的连接(就像多线程应用程序中的真实线程一样)。

您不能使用 psycopg2 的内置事务处理。

【讨论】:

  • 是的,这就是我写的。但这远非理想,因为您有效地将绿色线程的数量限制为池大小。其他绿色线程必须等待可用的连接(如果 db 重应用程序)。
猜你喜欢
  • 2010-12-26
  • 2013-10-16
  • 1970-01-01
  • 2018-09-13
  • 2012-02-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多