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.
> 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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
