On Feb 4, 12:41 am, Chris Withers <ch...@simplistix.co.uk> 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 sqlalch...@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.
