I should say that its not "wrong" to have a session shared among
threads, just that the usage of that session needs to be synchronized.
with the issue youre having specifically, it seems like a single
Connection is open with cursors in one thread, and another thread is
trying to close it. this would correspond to SessionTransaction
behavior since thats the usual case where a Session holds onto
Connections; so youd have to make sure only one thread at a time does
a flush(). also the Session only has one SessionTransaction going on
at a time, opening a second one gives you a "proxy" to the first one.
you would be better off to try to keep your module-level Session
limited to non-flush operations, and use expunge/save/update to move
objects between the module-level session and the local "working"
sessions, or even better limit your module-level Session to read-only
operations and use the local Sessions to load new copies of the
objects you want to manipulate for write operations.
if you synchronize access tot
On Sep 22, 2006, at 5:05 AM, Sébastien LELONG wrote:
>> are you using a distinct Session for each thread ? or are you using
>> some module-level Session that is shared amongst threads ? the
>> latter is not supported.
> Sessions are shared amongst threads... I should have mentioned
> it... This
> explains the problem as it's not supported. The reason sessions are
> shared is
> because in a muti-threaded application, data/objects managed by SA
> in a
> thread could be different in another, due to the SA's cache
> (identify map).
>
> The problem is how to have an identity map, shared with all
> threads, when you
> use SA with a multi-threaded web framework, such as cherrypy. I
> tried using:
> - session_context.set_current(the_shared_session) within the
> cherrypy.server.on_start_thread_list
> - the "scopefunc" argument of SessionContext, exactly as described
> in the doc
>
> Both result in having the same identity map amongst threads, but
> produce the
> errors described before. I'm surely missing something but can't
> find any
> information about it. How would you deal with such a problem ?? Do
> I need to
> clear sessions after each cherrypy request and avoid caching ?
>
>> are you using any explicit SessionTransactions ?
> Yes.
>
>> are you using any explicit engine/connection operations, or strictly
>> Session/Query operations ?
> Only Session/Query operations.
>
>> do you have garbage collection disabled ?
> No.
>
>
>
> Thanks for your reply and your help.
>
> Cheers,
>
> Seb
>
> --
> Sébastien LELONG
>
>
> On Wednesday 20 September 2006 18:43, Michael Bayer wrote:
>> i think the error youre getting is a good thing; it shows that
>> cursors are hanging open on a single connection before it gets back
>> to the MySQLDB.
>>
>> so here are some questions:
>>
>> are you using a distinct Session for each thread ? or are you using
>> some module-level Session that is shared amongst threads ? the
>> latter is not supported.
>>
>> are you using any explicit SessionTransactions ? if so, same
>> question - are they used local to a single thread, and properly
>> closed out before a request is completed ?
>>
>> are you using any explicit engine/connection operations, or strictly
>> Session/Query operations ?
>>
>> do you have garbage collection disabled ?
>>
>> On Sep 20, 2006, at 4:32 AM, Sébastien LELONG wrote:
>>> OK, I've just tried the patch.
>>>
>>> I've checked out SA from svn at revision 1873, applied the patch,
>>> and tested
>>> the whole, using several cherrypy threads (thread_pool = 10).
>>>
>>> This did not resolved the problem for me, as I get the error you
>>> described
>>> ("This connection still has X open cursors"). Here's the traceback:
>>>
>>>
>>> Traceback (most recent call last):
>>>
>>> File "/usr/lib/python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/
>>> cherrypy/_cphttptools.py",
>>> line 110, in _run
>>> applyFilters('before_finalize')
>>>
>>> File "/usr/lib/python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/
>>> cherrypy/filters/__init__.py",
>>> line 151, in applyFilters
>>> method()
>>> File "/home/slelong/Documents/Projects/dsf/tucos/filters/
>>> audit.py", line 94,
>>> in before_finalize
>>> self.feed_audit()
>>> File "/home/slelong/Documents/Projects/dsf/tucos/filters/
>>> audit.py", line 82,
>>> in feed_audit
>>> aa.flush()
>>> File "build/bdist.linux-i686/egg/sqlalchemy/ext/assignmapper.py",
>>> line 16,
>>> in do
>>> File "build/bdist.linux-i686/egg/sqlalchemy/orm/session.py", line
>>> 234, in
>>> flush
>>> File "build/bdist.linux-i686/egg/sqlalchemy/orm/unitofwork.py",
>>> line 211, in
>>> flush
>>> File "build/bdist.linux-i686/egg/sqlalchemy/orm/session.py", line
>>> 49, in
>>> commit
>>> File "build/bdist.linux-i686/egg/sqlalchemy/orm/session.py", line
>>> 61, in
>>> close
>>> File "build/bdist.linux-i686/egg/sqlalchemy/engine/base.py", line
>>> 235, in
>>> close
>>> File "build/bdist.linux-i686/egg/sqlalchemy/pool.py", line 207,
>>> in close
>>> File "build/bdist.linux-i686/egg/sqlalchemy/pool.py", line 212,
>>> in _close
>>> InvalidRequestError: This connection still has 1 open cursors
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Seb
>>>
>>> --
>>> Sébastien LELONG
>>>
>>> On Tuesday 19 September 2006 22:35, Michael Bayer wrote:
>>>> hey there -
>>>>
>>>> attached is another patch, which affects the instrumented Cursor
>>>> and
>>>> Connection objects so that it is impossible to return a
>>>> connection to
>>>> the pool without all cursors being closed; it throws an error
>>>> otherwise.
>>>>
>>>> after running all the unit tests with SA, the only time this
>>>> happens
>>>> is during a rollback(); i added an extra step to rollback to
>>>> explicitly close all open cursors after rolling back to fix that
>>>> issue.
>>>>
>>>> so when you apply this patch, im hoping that it either fixes the
>>>> problem, or you suddenly get lots of errors saying "This connection
>>>> still has X open cursors", which will pinpoint exactly where
>>>> cursors
>>>> are staying open when connections are being returned to the pool.
>>>>
>>>> because it will potentially raise a bunch of errors im trying to
>>>> hold
>>>> off on committing this patch just yet.
>>>>
>>>> give it a try ! also attached to ticket # 306.
>>>
>>> --------------------------------------------------------------------
>>> --
>>> ---
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys -- and earn
>>> cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Sqlalchemy-users mailing list
>>> Sqlalchemy-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
>
> --
> Sébastien LELONG
> 01 56 28 52 46
> [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlalchemy-users mailing list
> Sqlalchemy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
