On Oct 15, 2009, at 3:32 PM, Jeff Cook wrote:
> > And when things _do_ work, there are serious caching problems. > Sometimes it gives me the transaction rollback error, sometimes it > gives me an old version of the page, and sometimes it gives me a > current version of the page. I assume this has something to do with > what connection is getting used. How can I remove these problems? > Would pool_recycle be of any use? there's no flag that is going to make your program work. your app is buggy, plain and simple. You need to do a code review, ensure no exceptions are being squashed, do some ab testing, and watch your logs. its likely theres just one activity in your app, maybe two, screwing everything up. the longer you just try to guess the cause and try random things the more confused things will seem. SQLSoup doesn't have anything to do with connection pools or transactions, its basically a thin layer over creating mappers and Query objects. It uses the same Session as everyone else, using the threaded ScopedSession to keep things local. And a default setup of Pylons does catch errors and roll the session back. There's also little to no "caching" used by the session and certainly not across requests unless you've worked very hard to store everything in global variables across requests. > > On Thu, Oct 15, 2009 at 1:27 PM, Jeff Cook <cookieca...@gmail.com> > wrote: >> I see. So Pylons should handle this by default, but it's not doing >> so? >> That's highly disappointing. Clearly, something is quite incorrect >> here. Is my usage of SQLSoup causing rollback not to run? >> >> On Thu, Oct 15, 2009 at 1:16 PM, Michael Bayer <mike...@zzzcomputing.com >> > wrote: >>> >>> Jeff Cook wrote: >>>> I don't fully understand what you're talking about. I have this >>>> error >>>> and I need to make it stop. I just want SQLAlchemy to connect, >>>> run the >>>> query I instructed, and give me the results back and do this >>>> reliably >>>> without necessitating consistent server restarts. Thus far, it's >>>> been >>>> a serious pain managing connection errors and so on. SQLSoup may >>>> complicate this because they have no mention anywhere in their docs >>>> explaining the necessity to close your connections, and all >>>> methods I >>>> tried (explicit session.close()s at the end of each query, explicit >>>> db.close()s, and now autoflush=True) to make sure that the >>>> resources >>>> are being returned correctly to the pooler have failed and caused >>>> other blow-up problem attacks. >>> >>> none of the statements regarding SQLA in that paragraph are >>> accurate. >>> close() is not needed, autoflush=True is the default setting (did >>> you mean >>> autocommit? that's a feature better left off), SQLAlchemy always >>> returns >>> resources to their original pooled state when a transaction is not >>> in >>> progress. >>> >>> What is necessary, however, is that you must call rollback() when an >>> exception is raised. I see you're using Pylons, the default Pylons >>> template establishes this pattern within the BaseController. >>> >>> unfortunately there is no feature within SQLAlchemy that can "fix" >>> your >>> issue. Your application needs to get a handle on transaction >>> failures. A >>> transaction is only "invalid" if an error were already raised in a >>> previous operation within the same transaction, and you haven't >>> attached >>> any stack trace for that. >>> >>> >>> >>>>> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
