On Feb 7, 7:24 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > 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.
Don't see why that should be a problem. Both sync and async functions all eventually call a finish() method, which is where I've added an elixir.session.remove(), with elixir.session being a scopedsession. Seems to be working fine so far. > 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. I'm not sharing transactions, but why can I only have one transaction per request ? What if I want to save transactions only for the "critical areas" of my code where race conditions can exist, rather than the entire request, reads included ? This might be a moot point since I'm currently using MyISAM which has no transaction support, but if I was using say InnoDB would there not be tangible downsides to wrapping everything inside a transaction, including non-database CPU- bound code ? > > 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 sqlalchemy@googlegroups.com. > > To unsubscribe from this group, send email to > > sqlalchemy+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://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 sqlalchemy@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.
