Since version 2.3, the pyscopg2 driver implements the two-phase commit extension of the DB API specification version 2.0. So I'm keen to pick it up and implement Storm's support for two-phase commit on top of the DB API 2.0 interface.
The idea would be to add a prepare() method to the Store class, as proposed by earlier comments in this bug. Invoking prepare() on a backend that doesn't support the DB API two-phase commit extension would raise NotSupportedError, as recommended in comment #4. Then commit() or rollback() would transparently perform the second phase of the commit, if prepare() was called, as suggested in comment #1.
We might also want to have a begin(transaction_id) method on the Store class, accepting a unique string identifier. This would call the backend's tcp_begin() DB API method under the hood, and can be used by transaction managers.
Integration with ZStorm would be done using the above API, and probably adding something like a set_tpc(flag) method to ZStorm to enable/disable two-phase commit (it would be off by default).
Another option would be to explicitly add two new methods, e.g. tcp_commit() and tcp_rollback(), to clearly mark the difference with commit() and rollback(), though I'm not sure how useful that would be and what the possible use cases are.
Hi there! I'd like to revive this bug.
Since version 2.3, the pyscopg2 driver implements the two-phase commit extension of the DB API specification version 2.0. So I'm keen to pick it up and implement Storm's support for two-phase commit on top of the DB API 2.0 interface.
The idea would be to add a prepare() method to the Store class, as proposed by earlier comments in this bug. Invoking prepare() on a backend that doesn't support the DB API two-phase commit extension would raise NotSupportedError, as recommended in comment #4. Then commit() or rollback() would transparently perform the second phase of the commit, if prepare() was called, as suggested in comment #1.
We might also want to have a begin(transacti on_id) method on the Store class, accepting a unique string identifier. This would call the backend's tcp_begin() DB API method under the hood, and can be used by transaction managers.
Integration with ZStorm would be done using the above API, and probably adding something like a set_tpc(flag) method to ZStorm to enable/disable two-phase commit (it would be off by default).
Another option would be to explicitly add two new methods, e.g. tcp_commit() and tcp_rollback(), to clearly mark the difference with commit() and rollback(), though I'm not sure how useful that would be and what the possible use cases are.
Thoughts?