On Jan 20, 2014, at 11:12 AM, pr64 <pierrerot...@gmail.com> wrote: > Hi, > > Strange behaviour with sqa in multi-process environment... already posted on > StackOverflow for a web app but still missing some understanding so posting > here. > > I've created an application where my "sqa calls" are encapsulated: My API's > methods always do the same kind of stuff: > 1- request a session > 2- do my stuff - mainly requesting the db through session.query(...) > 3- eventually: > - modify some mapped object attributes > - and write to db (session.commit()). > > Several consecutive calls to my API's methods return the same session object > as long as I'm in the same thread which is the required behaviour. Some > commits happen but the session is always the same (expire_on_commit = False) > > # this factory is thread safe: a session object is returned (always > the same) to the > # caller. If called from another thread, the returned session object > will be different > session_factory = sessionmaker(bind=engine, expire_on_commit=False) > session_maker = scoped_session(session_factory) > > # to get a session: > session = session_maker() > > If I fork another thread, using the API is still safe since the first step > (getting a session) will return a new session instance (due to scoped_session)
First of all, “fork another thread”, I’m assuming you mean, “fork a child process”. So in that case, you should be aware that no DBAPI I’m familiar with is consistently safe in which to move a connection object over the process boundary. If a new process is created, the engine used in that process must have an empty connection pool, meaning you’re either using NullPool or you’re creating a new engine in the new process. Any Session object that has begun a transaction in the parent process is absolutely not a candidate for continued use within the child process as it is already holding onto a connection.
signature.asc
Description: Message signed with OpenPGP using GPGMail
