On Sep 29, 2010, at 11:03 AM, tom wrote: > First, thanks for that quick answer, that explains it. I turned > autocommit on, and it works again. > > That leads me to this question: I do have session.commit() sprinkled > throughout my code without any "except: rollback()" blocks, can that > lead to problems down the line? I had the impression that rollback is > called automatically anytime a commit fails, but I'm not so sure > anymore.
If the session has autocommit on, then the commit() calls are moot (and slightly wasteful since it opens a no-op tranasction then closes it). The rollback is also always implicit, since in fact every operation, not just errors, results in connection resources being restored to the connection pool when the operation is complete, which unconditionally performs a rollback. "autocommit" isn't the current "mainstream" way to do things, usually for web apps we recommend one session per request, which maintains a transaction until commit() or rollback() is called, using an enclosure scheme like that described at http://www.sqlalchemy.org/docs/orm/session.html#lifespan-of-a-contextual-session . > > > On Sep 29, 4:07 pm, Michael Bayer <[email protected]> wrote: >> On Sep 29, 2010, at 7:13 AM, tom wrote: >> >> >>> Hey, >> >>> I'm applying finishing touches to my web app before rolling it out, >>> when this strange error occurs: >> >>> sqlalchemy.exc.InternalError >>> InternalError: (InternalError) current transaction is aborted, >>> commands ignored until end of transaction block 'SELECT count(1) AS >>> count_1 \nFROM personal_message \nWHERE personal_message.receiver_id = >>> %(receiver_id_1)s AND personal_message.read = % >>> (read_1)s' {'receiver_id_1': 1, 'read_1': False} >> >>> Now, this hasn't happened before, and as far as I can tell I haven't >>> touched the concerning code recently. Googling the error doesn't turn >>> up anything useful, I'm not even sure it has to do with Sqlalchemy >>> (I'm using version 0.5.8, with Postgres). >> >>> Any pointers in the right direction would be greatly appreciated. >> >> when an integrity error is issued by Postgresql, such as attempting to >> insert a primary key that already exists, the ongoing transaction is then >> marked as invalid. If you try to do anything else in the transaction, you >> get that error. >> >> The underlying reason from a Python interaction perspective is that the >> session or connection you're using has encountered an error, but the >> transaction was not rolled back, and the application proceeded with that >> same connection. In a web applciation, the simplest cause of this is that >> one web request is re-using the session or connection from a previous >> request that raised an error. Theres myriad other variants of that >> sequence but that is the most ordinary one. > > -- > 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.
