I've added the /05/ docs to "disallow" in our robots.txt, since Google insists upon putting 05 hits above all else, and those documents are not as well written as the current ones.
That paragraph is now rewritten in a simpler format at http://www.sqlalchemy.org/docs/orm/session.html#lifespan-of-a-contextual-session . My recommendation would be to call scopedsession.remove() at the end of a request. Though with an "async" server like Tornado, though I haven't used it, I'm not sure that "thread local" sessions, that is the default behavior of a "scopedsession", are even appropriate - you'd need to devise some way to link a specific Session to a request, and when that request is over, simply close() that Session. Perhaps i should add a note to that documentation section that this assumes a synchronous, possibly multi-threaded web application. In your case your goal should be to 1. consider a single Session's life span as a single transaction with the database and 2. ensure that you have one and only one transaction per request, not shared with any other request. If you are sharing a single transaction with multiple requests, that would quickly lead to errors of the kind you are describing. On Feb 7, 2011, at 7:46 AM, Romy wrote: > So I haven't really given too much thought to the setup until recently. Thus, > some of this could well be silly. > > Up until now it's been a global scopedsession per each Tornado process, with > autocommit=True, pool_recycle=14400, pool_size=20. > > IIRC, the autocommit=True was a quick solution to the "MySQL has gone away" / > "Can't reconnect until invalid transaction is rolled back" class of problems. > To this day I don't know of the real pros / cons of using autocommit=True vs > long running transactions. I'm assuming there's some overhead to starting a > transaction on every flush, but I have no clue if this is negligible, or the > only overhead involved, etc. > > Of the 5 approaches for web frameworks here, I chose the last -- do nothing. > However, some of the requests use read-only queries that don't require a > commit or rollback, and I never explicitly call close or remove. Is this a > mistake ? If so, what can happen ? > > Pretty sure I'm going to be switching to a autocommit=False model, and adding > a session.close() at the end of each request (probably at the framework > level), to have a new session for each request. I think this will help with > various problems that have been popping up, including ObjectDeletedErrors and > StaleDataErrors. On that note, I still don't get why you'd ever use > autocommit=True without changing the default expire_on_commit to False ? > > I've also had occasional "MySQL is using too many connections" errors pop up > given the current setup. Perhaps the reason is obvious to someone given my > current setup ? > > Cheers, > > R > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > 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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
