[ZODB-Dev] transaction observer iface

[hazmat at objectrealms.net]

On Fri, 20 Feb 2004, Kapil Thangavelu wrote:
>
>> i'm interested in implementing an observer interface for transactions,
>> something along the apis of the following. i was curious if there was
>> interest/support for this sort of development.
>
> Every transaction participant is already an observer, isn't it? It seems
> like the only functionality you added is notifyObjectRegistered();
> everything else is accessible through tpc_*.  Maybe I misinterpreted.
>

I would rephrase to every txn participant's data manager is an employee of
the transaction ;-). while data mangers do receive txn messages and
perform work on its behalf, and i have used that in past to recieve
notifications, there are a couple of ordering and operational issues that
make such usage less than ideal. namely for observers wishing to alter the
state/data of the application based on a state/transition change of the
transaction, issues of jar ordering become an issue in order for
subsequently registered jars to recieve the proper messages, in some cases
this sort of operation isn't supported at all. with an observer interface
on the transaction, the observer can perform additional manipulation of
application/data without concern for such.

also to clarify i'm not interested in tpc_* messages, which are more about
the internal mechanics of transaction state change but instead in the
public/application api of the transaction for state change.

jim brought on irc today that zodb4 style transaction and data manager
semantics were going to be backported and integrated with future revs of
zodb3. i haven't really though through how this interface would adapt to
that, as data managers are responsible for managing their participants
directly there.

>> class ITransactionObserver:
>>
>>     def notifyAbort( txn ):
>>         """
>>         invoked when the transaction is about to abort
>>         """
>
> FWIW, I've named event-ish methods notify*() in the past, but now I think
> a much better convention is to name them before*() or after*().  So I
> might name the methods of the interface beforeAbort(), beforeCommit(),
> afterBegin(), and afterObjectRegistered().  The difference between before
> and after is often important.  For example, before*() often allows veto,
> while after*() usually doesn't.
>

i agree and perhaps i didn't make it clear in the interface but the
proposed ones were all notifications before the state change occurs
(before*). perhaps the after* should be included in the iface as well? the
only after message i can think of a use case for is afterCommit.

cheers,

-kapil