[Libpqxx-general] Two phase commit

[Jeroen T. Vermeulen]

Hi Maurice,

Wow, nearly lost your message in a sea of notifications of spam posts. 
Those bastards are getting really tricky now: they rep-post an existing
bug comment but with a link inserted.  So the comment looks legit until
you notice the URL.


On Thu, August 20, 2009 15:45, Maurice Gittens wrote:

>> I think we would want the API to align well with the mental-model used
>> with
>> XA compliant TM; keeping things nice and simple in the process.

I suppose XA+ never went anywhere...  But as I said I haven't kept track
much.


>> A suggestion for integration into pqxx follows. (I have no idea if this
>> suggestion
>> aligns well with the pqxx design policies).
>>
>>   pqxx::transaction_monitor txmon.
>>
>>    txmon.add_connection("conn1", "a connection string for a postgres
>> db");
>> // creates new connection
>>    txmon.add_connection("conn2", pqxxConnection1); // use existing
>> connection
>>
>>   pqxx::transaction<pqxx::read_committed> tx(txmon, "a_tx_id");
>>
>>   // do stuff with the connections;
>>      tx("conn1").exec("select * from pg_class;");

I'm not sure I understand all the whys and hows of the API you had in
mind.  Why the extra ("conn1") after tx here?


>>   // a managed transaction does not have begin, commit, rollback methods
>>      pqxx::managed_transaction mtx = txmon("conn2");
>>      mtx.exec("select 1")'

I think abort and commit would still have to be there; but a commit could
turn the transaction into something else that still needs a final go-ahead
for the full commit.  That part could be as simple as two extra methods on
the connection to commit or abort a given prepared transaction.

The only ugly part here is that commit's effect on the database will
initially look very much like an abort: any changes the transaction made
are suddenly gone again for the time being.


Jeroen