Moving over to zope-dev... Martijn, don't worry. I'm not going to change designs in mid-stream. But I still have to think thru all the possibilities, perhaps covering ground that you've already explored and left behind. From: Martijn Pieters <mj@digicool.com> Sent: February 24, 2000 03:24 AM Subject: RE: [Zope] Private Product Objects (was: object icons)
(Events are called using ZClient, because the Events have to be called independent of current web requests, and you do need a HTTP REQUEST context).
I assumed from the beginning that the event Dispatcher would fire events with RPC (ZClient or something like it) for the reasons you mention, plus the fact that the thread for the event is allocated by existing Zope mechanisms. Then I started thinking about transactions and atomicity. You don't want a system failure to result either in loss of an event or duplication of an event. But how can you ensure that in the case of the Scheduler? So, I started wondering how to atomically coordinate the updating of the Schedule catalog (to disarm the event) with the execution of the event's action method. I thought of having the Dispatcher wrap a transaction around the event's transaction, but that doesn't solve the problem. Transactions don't nest well. You could still have a failure between the end of the event's transaction and disarming of the event. I thought of using LPC (direct call) instead of RPC so that the Dispatcher could define the transaction in which the event runs and include the Schedule update in the same transaction. That sound great from the transaction point of view. But then the Dispatcher would have to manage threads for the events (not KISS), plus there would be no HTTP REQUEST context, etc. In short, I don't have a solution. Any ideas? -- Loren