François Wautier wrote:
> I moved the "connect" to the method handling the data and the problem > disappeared. yeah "connect()" should generally be localized as much as possible. > > It would be easy enough to make sure all the "flushes" are done in a single > thread of execution, but can you share a session across multiple thread if > you ensure that anything dealing with connection (most methods of the session > save maybe for "save") are executed by a single thread? IOW if you modify an > object belonging to a session in a different thread, will the session notice? you sort of can, but you have to be careful, as any load operation also writes data into the session. Load operations trigger not only when you run a Query against that session, but also when any relations on instances trigger a lazy load operation. if two threads each load an instance with the same primary key identifier, they could compete for which one actually gets placed in the session and the other one gets knocked out. also a flush() is modifying the state of the underlying unit of work which is also not going to well tolerate other instances being loaded into that session. you might want to look into SessionContext which can manage Sessions per thread, and also can be customized to manage Sessions based on other criterion, such as for a GUI app on a "per-widget" basis,for example. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~----------~----~----~----~------~----~------~--~---
