[Zope-dev] Running methods on Zope startup.

[grahamd@dscpl.com.au]

On Apr 25 10:02, Toby Dickenson <tdickenson@devmail.geminidataloggers.co.uk> wrote:
>
> Subject: Re: [Zope-dev] Running methods on Zope startup.
>
> On Wed, 24 Apr 2002 21:56:52 -0600 (MDT), grahamd@dscpl.com.au wrote:
> 
> >Imagine a situation similar to database connections. With database connections
> >when you create it you can indicate that you want the connection established.
> >Now when Zope is restarted, those database connections will be automatically
> >restarted when Zope restarts. Although, I am not sure whether this is when
> >Zope actually starts or when the next request using that database happens.
> 
> The connection is made when the next request comes in, and the
> connection is broken when ZODB decides it is time to deactivate the DA
> object; which is hopefully only happens if the connection has not been
> used for a while.

Ok, wasn't quite sure which way it did it.

> >I can't rely on
> >the connection only starting when someone tries to access the resource, I
> >want it to happen straight away upon Zope restart.
> 
> I think you will have to fight ZODB if you need:
> * The connection to always stay up
> * one connection per instance of a class stored in ZODB
>   (like database adapters)

On the latter point of searching automatically for all instances of a
particular type and automatically starting up something for it, that was
my first thought and in the end I figured that could get real inefficient.
That is when I came to the lowest common denominator of a "Startup"
folder and figured that a manual association could be made. At least
an association with a product instance which could then do the hard
work.

Anyway, I know I will potentially have to fight ZODB though, as I can see
lots of instances where I will need to recognise existance of objects in ZODB
and create parallel transient objects which do something in relation to
those instances. Given I am new to Zope this might turn out to be messier
than I think it will.

> >Can anyone point me to such a Zope product. I have started looking at how
> >to do it myself and have some of the bits in place. The first issue is that
> >when the "initialize()" method in the product "__init__.py" file is called
> >not all Zope startup has occured, so it is too early to trigger things from
> >that point.
> 
> Initialize looks like the right place to me. What do you think this is
> too early for?

Not all products might have been initialized at that point, plus possibly
other stuff as well in Zope itself. The asyncore loop also isn't running
at that point. For reasons unknown I have also already found that if I
create some separate code of my own from a thread started in the initialize
routine, that even though the main thread of control returned back into
Zope to finishing doing everything and start up asyncore, Zope wouldn't then
service any requests. Was most strange, would only work if I created the
separate thread from callback in asyncore once it had been started.

> One thing that might be nice to add is *dependencies* between product
> initialization. Today you have to rely on Zope sorting product names
> alphabetically before initialization, which slightly sucks.

This is an issue with the idea of a "Startup" folder as well as what
order to you execute register methods. First thought was to have ability
to say that method relied on other method being run first, but then
figure that for simplicity, might be easier to let user indicate specific
order they were run through management interface.

> >The next problem is getting an appropriate context to be able to start making
> >calls into Zope objects. The "initialize()" method gets a product context,
> >but doesn't have public access to the application context. Is there some way
> >of accessing the Zope application context and thus root folder where you
> >don't otherwise have a handle to it?
> 
> Public access? no. currently you have to hack through the jar.
> 
> I agree there should be an API for this.

But then, as suggested by someone else, if a startup mechanism is inbuilt
the hook would be placed in the Application.py file which has access to
the application context anyway.

Feedback appreciated.

--
Graham Dumpleton (grahamd@dscpl.com.au)