On 8 June 2010 11:44, Chris Withers <chris@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