On Aug 7, 2012, at 6:27 PM, Lucas Manfield wrote:

> Hello,
> 
> I've been unable to shake 'MySQL has gone away' errors in my application.  
> Here's my setup:
> 
> It's a pretty classic REST API built on top of Flask and MySQL with a 
> scoped_session
> 
> engine = create_engine('mysql+mysqldb:/********', 
>                         convert_unicode=True, 
>                         pool_size=3, 
>                         pool_recycle=60)
> db_session = scoped_session(sessionmaker(autocommit=False,
>                                          autoflush=False,
>                                          bind=engine))
> 
> However, I also have another component of the project that runs continuously 
> in the background and occasionally acts upon the same data model.  Its using 
> the same session initialization code. Basically, every couple seconds I check 
> the data model and occasionally spawn off a new thread that retrieves 
> external data and updates the database accordingly.

when you do this, you need transfer the ORM objects from one thread to the 
other.  You can do this either by detaching them from the parent thread's 
session, then add() them into the session that is local to the new thread, or 
you can use session.merge() to copy the state of those objects from one thread 
to the other.  session.merge() accepts a flag load=False which will prevent it 
from hitting the DB in order to synchronize, it will just accept what you give 
it into the new session.


>  I assumed that scoped_session would just handle all this automatically,

scoped_session is nothing more than a ten line wrapper around Python's 
threading.local().    It basically makes it so that when you call upon 
"Session()" or any of its methods, you operate on a Session object that happens 
to be associated with the current thread.   It does not provide any kind of 
thread safety to the Session itself.   Objects which are associated with a 
particular Session (we call this "persistent") need to refer to the Session 
whenever unloaded attributes are accessed, which means they are an extension of 
the Session's state and from that they are an extension of your MySQL 
connection - hence the whole stack of data is not threadsafe.




-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to