[ZODB-Dev] Re: [Zope-dev] Zope 2.4.0 CopySupport changes seem wrong
Steve Alexander
steve@cat-box.net
Fri, 27 Jul 2001 17:12:49 +0100
Hi John,
John D.Heintz wrote:
>
> I'll offer any help I can to you.
Thanks. That's much appreciated.
> I have some ideas to contribute, all of which have been coded into the
> TransactionManagement.py file include in ZCF 0.5.
> See: http://www.zope.org/Members/jheintz/ZODB_CORBA_Connection/index_html
I'll take a look at this.
> def attach(self, _id=thread.get_ident, force=0):
> "map _id() to this transactions for get_transaction(_id)"
>
> def detach(self, _id=thread.get_ident):
> "un-map _id() to this transactions for get_transaction(_id)"
So I guess this is for having many threads to one transaction. I suppose
that's important for the way CORBA works.
> def registerCommitCallback(self, func, *args, **kw):
> "Register callback when Transaction has totally finished commit"
Does this run only on a successful finished commit, or does it run on
anything that causes tpc_finish?
> def commit(self, subtransaction=None):
> ZODB.Transaction.Transaction.commit(self, subtransaction)
> if subtransaction is None and self._onCommitCallbacks is not None:
> for callback, args, kw in self._onCommitCallbacks:
> try:
> apply(callback, args, kw)
> except:
> LOG('ThorTransaction',ERROR, 'Error processing ?'
> callbacks',
> error=sys.exc_info())
> self._onCommitCallbacks = None
I guess I can answer my own question -- you only run this on a
successful commit. What commits the work done in the callbacks?
> Note: The reason we needed postCommit() and registerCommitCallback()
> was that some of our _finish() processing was trying to send the ID of
> a newly created object to an external system that was synchronously
> calling back into our ZODB (on another connection) and was unable to
> find the new object. This was the side-effect that until all of the
> finish() calls have been made a callback like this will likely fail.
I had a similar problem with a race condition when I wanted to
invalidate a RAM Cache Manager after certain things had changed in a
transaction. I solved it by running the invalidation in a separate
transaction that runs after the original transaction is completely
successfully committed.
--
Steve Alexander
Software Engineer
Cat-Box limited