On Jun 10, 10:08 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > First off, the absolute recommended behavior for SQLite if a file-based > database is to not use pooling. I would suggest you use a NullPool to > eliminate any connection pooling. Some detail on this > athttp://www.sqlalchemy.org/docs/reference/dialects/sqlite.html#threadi.... > Seems like I mention it in the linked thread as well. >
Indeed. I understand about NullPool, and the setup I'm using is a test setup for multi-db operation. I would expect the session.remove() to clean up any SQLA connections used during the request, but it's not happening some of the time - I was hoping to find the cause; of course if I switched to NullPool the problem would go away. > You then need to ensure no sqlalchemy-session-bound objects in your web > application are shared between threads. When you put things into your HTTP > session, assuming its an in-memory HTTP session, make sure objects that go in > there arent attached to a SQLAlchemy session. Use expunge() or similar for > this. Calling remove() at the end of the request will work, except for the > fact that a concurrent thread might be accessing the HTTP session before you > get that far. In the failing case, requests are not actually happening concurrently - mod_wsgi just happens to use different threads for servicing the sequential requests, which are a second or two apart. The problem is caused by a connection sometimes not being found when session.remove() is called. The connection is always created in response to a query to get a User object from an integer ID stored in the session. While the User object is a SQLA mapped object, it's not stored in the session, only the ID is. Note that the problem occurs during clean up via session.remove() (connection not found to return to pool) but manifests itself on the next request (a second or two later). I'm wondering if there's some reason why an opened connection might sometimes not be registered properly [ has() returning False ] which is why it's not returned to the pool. Concurrent thread access to the session isn't (I believe) happening in this case as the server is on my local test machine with no other load than me accessing via Firefox locally. There are concurrent requests but only for static files. > I would recommend using cookie based HTTP sessions in any case (see Beaker >for this functionality). I presume you mean where all session state is stored in the cookie. I can do this but I'm working on a framework component which also needs to support server-side sessions. > That thread regarded someone using an extremely rare tool called PyISAPIe, > which had threading bugs in it. That doesn't apply to a basic mod_wsgi > configuration. I see now. It was a clutching-at-straws kind of thing :-) Thanks & regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
