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?
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 -~----------~----~----~----~------~----~------~--~---
