From: Loren Stafford [mailto:lstaffor@dynalogic.com]

Moving over to zope-dev...

Good idea.

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.

Why should this be atomic? The integrity of the Catalog is most important. First, in it's own RPC call, update the catalog (disarm or reschedule next call). Then, separate from this, call the Event. Yes, you run the risk of not calling a certain event in case of a system failure. But in that case the event could not have run anyway. I'd say, solve it like I'd do, and move any reliability issues to a next release. We are replacing cron here, not MessageQueue. -- Martijn Pieters, Software Engineer | Digital Creations http://www.digicool.com | Creators of Zope http://www.zope.org | mailto:mj@digicool.com ICQ: 4532236 | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 -------------------------------------------