On Feb 4, 12:41 am, Chris Withers <[email protected]> wrote: > The problem is that session2 (and it's engine) are only created in a > small part of the code, while session1 is created in a much wider > encompassing framework. As such, there's no obvious way to get session1 > to the piece of code that calls commit on session2. > > (an aside: what happens here, assuming the first of your possibilities: > session1.commit() > raise RuntimeError('something goes bang') > session2.commit())
This is the reason why you need a transaction manager when using two- phase transactions. The second transaction will remain in a prepared state (modifications not visible to other transactions, still holding any locks), even after a database crash and restart. The transaction manager needs to ensure that all transactions in a group either get committed or are rolled back. This should preferably be an automatic process, as any prepared transactions left hanging will grind your database to a halt pretty quickly. Ants -- 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.
