scoped_session 中跨进程边界

我正在使用 SQLAlchemy 和多处理。我还使用scoped_session，因为它避免共享同一个会话，但我发现了一个错误及其解决方案，但我不明白为什么会发生这种情况。

你可以在下面看到我的代码：

db.py

engine = create_engine(connection_string)

Session = sessionmaker(bind=engine)
DBSession = scoped_session(Session)

脚本.py

from multiprocessing import Pool, current_process
from db import DBSession

def process_feed(test):
    session = DBSession()
    print(current_process().name, session)

def run():
    session = DBSession()
    pool = Pool()
    print(current_process().name, session)
    pool.map_async(process_feed, [1, 2]).get()

if __name__ == "__main__":
    run()

当我跑步时script.py输出是：

MainProcess <sqlalchemy.orm.session.Session object at 0xb707b14c>
ForkPoolWorker-1 <sqlalchemy.orm.session.Session object at 0xb707b14c>
ForkPoolWorker-2 <sqlalchemy.orm.session.Session object at 0xb707b14c>

请注意，会话对象是相同的0xb707b14c在主进程及其工人（子进程）中

但是如果我改变前两行 run() 的顺序：

def run():
    pool = Pool() # <--- Now pool is instanced in the first line
    session = DBSession()  # <--- Now session is instanced in the second line
    print(current_process().name, session)
    pool.map_async(process_feed, [1, 2]).get()

而我跑script.py输出再次是：

MainProcess <sqlalchemy.orm.session.Session object at 0xb66907cc>
ForkPoolWorker-1 <sqlalchemy.orm.session.Session object at 0xb669046c>
ForkPoolWorker-2 <sqlalchemy.orm.session.Session object at 0xb66905ec>

现在会话实例不同了。

要了解为什么会发生这种情况，您需要了解什么scoped_session and Pool事实上确实如此。scoped_session保存会话注册表以便发生以下情况

• 你第一次打电话时DBSession，它创建了一个Session注册表中为您提供的对象
• 随后，如果满足必要条件（即同一线程，会话尚未关闭），则不会创建新的Session对象并返回之前创建的Session对象返回

当您创建一个Pool，它创造了工人__init__方法。 （请注意，启动工作进程没有什么基础的__init__。同样有效的实现可以等到第一次需要工作人员后再启动它们，这在您的示例中会表现出不同的行为。）当发生这种情况（在 Unix 上）时，父进程forks对于每个工作进程来说，这涉及操作系统将当前正在运行的进程的内存复制到新进程中，因此您实际上会在完全相同的位置获得完全相同的对象。

将这两者放在一起，在第一个示例中，您将创建一个Session在分叉之前，在创建过程中将其复制到所有工作进程Pool，产生相同的身份，而在第二个示例中，您延迟了创建Session直到工作进程启动后才对象，从而导致不同的身份。

重要的是要注意，虽然Session对象共享相同的id， 他们是not同一个对象，从某种意义上说，如果你改变任何关于Session在父进程中，它们不会反映在子进程中。由于分叉，它们恰好共享相同的内存地址。However, 操作系统级资源，例如连接are共享，所以如果您运行了查询session before Pool()，将在连接池中为您创建一个连接，然后将其分叉到子进程中。如果您随后尝试在子进程中执行查询，您将遇到奇怪的错误，因为您的进程在同一个确切的连接上相互干扰！

上述内容对于 Windows 来说没有意义，因为 Windows 没有fork().