On Feb 9, 10:48 am, Chris Withers <ch...@simplistix.co.uk> wrote: > Okay, but what does the transaction manager do that's different from > calling commit on session1 and session2 in order?
A TM should write to durable storage when a transaction group is prepared before committing any transaction. When doing crash recovery this information must be used to decide whether to commit or rollback the rest of the prepared 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. > > So how do you un-f?$k it then? ;-) For MySQL you can obtain the list of prepared transactions with the XA RECOVER command. You can then use XA COMMIT or XA ROLLBACK commands as appropriate to handle them. > I know that zope's transaction package aims to do just this, I wonder if > anyone's used that, or anything else, with SA to solve this problem? I've only used two phase for the relatively trivial case of doing filesystem updates atomically along with metadata updates in the database. The zope transaction package doesn't seem to have any disaster recovery story, but maybe I'm missing something. Depending on your exact environment and requirements you might also find an easier way, but be very-very careful with distributed transactions. It's a really hard problem to get 100% correct in the face of arbitrary software, network and hardware failures. 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.
