On Jan 25, 2012, at 10:05 AM, Joril wrote: > An entirely new database connection can resume this transaction by again > calling BEGIN PREPARED with the same XID. > > I'm sorry, but I can't find this command inside the Postgresql docs... Am I > missing something?
PREPARE TRANSACTION. Paraphrasing, sorry. > I'm trying to do a multi-request two-phase transaction too, so I thought I > could use the xid to refer to the same transaction from every request, but it > looks like BEGIN PREPARED doesn't exist, and if I issue a second "PREPARE > TRANSACTION 'samexid'" it complains that the "transaction identifier "xyz" is > already in use" Well you only PREPARE it once. Once you do that, it's present in pg_prepared_xacts. A second session can then "recover" that transaction, which means only that it can be committed or rolled back, by saying "COMMIT PREPARED 'xid'". So I guess the idea is that each web request does a new PREPARE TRANSACTION with a unique xid, then when the results of all those requests are ready to be committed, the "final" call then calls "COMMIT PREPARED" on the full list of xids. I probably mentioned this earlier but two-phase transactions are very hard to work with and aren't really well suited to stateless communication; if the client disappears for three hours or three weeks, the transactional state stays wide open in the database, locks and all, until some cleanup process goes in and emits ROLLBACK PREPARED on the stale xids. Using a session system, which could just mean extra tables/rows designed to store pending data specific to the workflow, is usually how this problem is handled. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@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.
