[Zope-dev] deciding whether to do work in tpc_vote or tpc_finish

[Laurence Rowe]

On 8 June 2010 11:44, Chris Withers <chris at simplistix.co.uk> wrote:
> Laurence Rowe wrote:
>>
>> Committing in tpc_vote is right so long as you ensure your data
>> manager sorts last, and that there are no other data managers in the
>> transaction which are using the same trick.
>
> Why does the latter part matter?
>
> (It is, of course, the situation I'm in, where zope.sqlalchemy is operating
> in non-tpc mode (sqlite doesn't support tpc :-/) and now I'm writing another
> data manager for a service that doesn't support tpc)

Your options then are:

* Use a database that supports two phase commit (you're using
sqalchemy, so that should be trivial).

* Queue up changes for the other 1pc system in the first, batching
updates to the second. While this moves the problem to the batch
process, it's easier to solve there as you can just add timestamps to
the data, and then know if any particular row was successfully pushed
into the second system or not in event of a power cut.

* Trust that any sqlite transaction will always be committed
successfully and add a data manager variant to zope.sqlalchemy that
commits in tpc_finish. You'll never get a write conflict error in
SQLite (it uses locking instead of MVCC, see
http://www.sqlite.org/lang_transaction.html and
http://www.sqlite.org/lockingv3.html), but you might end up in an
inconsistent state in event of a power cut or perhaps when you fill up
the disk.

Laurence