On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jul 19, 2007, at 2:08 PM, Arun Kumar PG wrote:
>
> > 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.
> >
>
> OK, this is exactly the issue; youre caching mapped objects, which
> have unfired lazy loaders, and then sharing those mapped objects
> among threads. The lazy loader needs to consult a session in order
> to load its contents, since thats where the ORM locates information
> about how to get a connection (for example, if your sessions are
> bound to engines, and not your tables, this would be essential). The
> session, when its inside of a SessionTransaction as well as within a
> flush() process, holds onto a single pooled connection to do its
> work. If another thread accesses the session during this time, youll
> get a conflict.
Will this be a problem even if I attach a new session per incoming request
i.e. thread handling request ? So basically it's because of having the same
copy of mapped objects ? How can I solve the above problem in existing way
without using a QueuePool ? By creating mapped objects per request ?
> 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.
>
> when you do that, the QueuePool will return the same connection for a
> particular thread which was already in use. this is part of what
> happens when you use create_engine('...', strategy='threadlocal').
> However it doesnt have any ability to stop you from sharing one of
> those checked-out connections with another thread. It shouldn't
> change anything here, actually; the session still checks out a
> connection, and holds onto it during a transaction or flush() and
> that's still the same connection it will hand out to any other thread
> during that time.
>
>
>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
