[Zope-dev] Scheduler product, anyone?

[Stuart 'Zen' Bishop]

On Mon, 7 Feb 2000, Loren Stafford wrote:

> > It may be possible to do this from within Zope and not involve cron
> > at all. Your Scheduler product could fire off a seperate thread
> > when its package is first loaded. Has the advantages of only attempting
> > calls when Zope is running, and being platform independant.
> 
> Great idea! However I can't quite get my mind around the implementation in
> Zope:
> 
> 1. Starting the Dispatcher on Zope start-up.
> The only place I can think to put this kind of initialization logic is in
> __init__.py of the product.

In here, or in a module that is imported from __init__.py.

> That code would have to look for any already-created instance and (if found)
> run it's Dispatcher method in a separate thread. Is there any way to do
> this?  I have a feeling I'm confused on this point. I seems odd for
> __init__.py to look for instances.

The module will only ever be instantiated once - this is how package
global variables are done. All you are doing is creating a package
global (which is actually a running thread object).

> 2. Does it make sense to provide for more than one instance of the
> scheduler? I can't think of a reason. But then you couldn't prevent someone
> from creating as many as they want, could you?

The process which needs to find the scheduled events (either a thread
or from cron) needs to look for them in a known location. The easiest
implementation of this would be to have a single object called 'Schedule'
stored in the root of the Zope tree. Now - if you make this Schedule
object a subclass of ZCatalog, then it will be trivial for an 'Event' object
to tell the Schedule object that it exists - just make the Event object
a subclass of CatalogAware, and make its default catalog name 'Schedule'
instead of 'Catalog' and all the work is done for you. In this scheme, you
end up with one central queue, but can scatter Event objects wherever you
feel like it. This simplifies the logic, as an Event object only needs
to be able to handle one event rather than maintaining a list.

If this Event object could be subclassed in Python products or ZClasses,
it would be possible to create custom applications that are Schedule
aware.

> 3. Managing separate threads.
> Will Zope's persistence and transaction mechanism provide all the mutual
> exclusion I need on the schedule queue? ...or do I need some kind of lock?

If you are accessing the ZODB like an external client would (HTTP, XML-RPC,
whatever) then there is no problem. It would be possible to access the ZODB 
directly like any other Zope thread, but then you would have to use the 
same transaction mechanics (this might be simple - you would have to go 
through the UML ZODB definition in the Resources section of zope.org or 
ask a Digicool employee nicely :-) )

-- 
 ___
   //     Zen (alias Stuart Bishop)     Work: zen@cs.rmit.edu.au
  // E N  Senior Systems Alchemist      Play: zen@shangri-la.dropbear.id.au
 //__     Computer Science, RMIT 	 WWW: http://www.cs.rmit.edu.au/~zen