[Zope-dev] Scheduler Transactions (was Private Product Objects)

[Loren Stafford]

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