Apologies for not responding for a while Was stuck in the project. Ok. So this is what happening The mapped objects are created during the first time request to the application. So create_engine is getting called one time only passing in the creator as a lambda: db_obj where db_obj is the ref to method returning MySQldb connection.
starting over again.. request comes, handled by a thread in the threadpool, check if mapped objects are already created or not. If yes return else create mapped objects (create_engine()... as mentioned above) and thread returned back to the pool. (FYI: this is an httpserver having a threadpool for request handling) Subsequent request now does not create mapped objects or create engine. It simply uses the existing mapped objects and does ORM actions. The problem was coming when lazy loading happens during multiple requests. I guess the underlying connection pool (in case of using creator approach) is not using threadlocal approach as different connections are checked in/out when I look at the pool log and exchanged as well among different request handling threads. Can that be the problem ? Also, is the underlying connection pool use threadlocal strategy in case of using creator approach while creating engine ? don't know if *strategy flag is for that ?* However, when i passed in a pool.QueuePool instance with use_threadlocal= True everything worked just fine. Any thoughts where the problem could be ? On 7/16/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > > On Jul 15, 2007, at 11:24 PM, Arun Kumar PG wrote: > > > Hi Michael, > > > > I figured out the problem. It was a connection sharing issue. Looks > > like different connection objects were getting returned from the > > pool (which was created using the creator approach in create_engine > > ()) when relations were getting loaded as a part of processing. Due > > to this sometimes connection swapping was happening among the > > different request threads. > > do you mean, multiple create_engine() calls were occuring ? or are > you talking about the issue i mentioned earlier, that lazy-loaders > were firing off against a session in a different thread ? does that > mean your mapped objects *are* in fact being used in threads other > than where they were created ? > > > > > I resolve this I created a threadsafe QueuePool and passed a class > > wrapping the same while creating engine. This helps the same > > connection getting returned for the same thread. > > can you please describe specifically what you mean here ? QueuePool, > i would hope, is threadsafe already. Or do you just mean you passed > the "threadlocal" flag to QueuePool ? that doesnt seem like it would > fix the session-related problem since that issue occurs when it holds > onto a single connection while flushing. > > i just need to understand what you did, since if theres any way i can > defensively prevent or at least document the situation its pretty > important. > > > > > > > > -- Cheers, - A --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
