On Fri, Jun 18, 2010 at 08:06, Laurence Rowe <l...@lrowe.co.uk> wrote:
> On 18 June 2010 01:24, Leonardo Rochael Almeida <leoroch...@gmail.com> wrote:
>> By the way, this issue is completely separate from the
>> two-phase-commit discussion that we had recently, since all the
>> connectors involved here are fully transactional.
> As you can see here:
> def tpc_vote(self, *ignored):
> self._finalize = 1
> def tpc_finish(self, *ignored):
> if self._finalize:
> try: self._finish()
> finally: self._registered=0
> The transaction manager is only doing one phase commit. It sorts first
> as it commits in the second phase. If you change the sort order, you
> lose the guarantee of transactional integrity.
For me this means that TM subclasses need to override tpc_vote and
implement a proper commit preparation   to assure they are
correctly participating in the TPC dance.
And if that is not the case, but you have, for example, more than one
MySQL connector, you are already in a situation where you can't
guarantee transactional integrity, so this discussion is actually
orthogonal to the sortOrder one.
> Perhaps a better way to solve this would be to include the zope
> transaction id in the table, then in the background thread only
> reindex the queued items with a tid <= the current tid of the
Possibly, but is there a way to know the id of a transaction that
hasn't been committed yet, to store it on MySQL? Besides, when working
with multiple mount points, you might have to store multiple TIDs, for
all storages involved, or else there should be a global transaction ID
that should be recorded everywhere, and I don't see the 'transaction'
package providing one.
In any case, does anyone oppose the existence of a .setSortKey() on
the TM class?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -