> > ...but it *appears* that when I start using > > transaction.session.bind_to.execute(stmt) directly, it is not part of > > the transaction. > > uh yeah...why would it be ? youre essentially pulling out the > original bind_to engine which has no idea about what particular > connection/transaction is used by the SessionTransaction.
I misunderstood that about how transactions work. Explicitly adding a connection makes sense (but was not intuitive). > > http://www.sqlalchemy.org/docs/unitofwork.myt#unitofwork_transaction_sql thanks for the link, I completely missed that; thought I'd looked everywhere. _ the fact that the deadlock was solved when I added the connection to the transaction tells me that psycopg runs in commit mode automatically (even though dbapi 2 says it should not). The psycopg docs reinforce this too : http://www.initd.org/tracker/psycopg/wiki/psycopg2_documentation#setting-transaction-isolation-levels this is a little annoying because deadlocks are hard to track down and there is still no way [that I can see] to tell sqlalchemy in an agnostic way : autocommit=False for my engine. I would think this should be allowed like create_engine(dsn, autocommit=1) or as a query string arg in the dsn. Anyway, I can live with forcing everything in a transaction but it is definitely a workaround since all I'm doing are selects. thanks, Kumar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
