[Grok-dev] Re: Triggering recurring events and executing tasks in the "background"

Gary Poster gary at zope.com
Thu Apr 10 21:40:19 EDT 2008

On Apr 10, 2008, at 7:51 AM, Malthe Borch wrote:
> On 10/04/2008, Gary Poster <gary at zope.com> wrote:
>> Now the job that will be performed asynchronously will be to call
>> Zope.Products.MyProduct.perform_index(catalog)
> Okay I see. Does the package then acquire a fresh copy of the
> ``catalog``-instance, local to its own ZODB connection or is there
> some trickery involved?

Right, no trickery.

> The reason I'm asking is that doing this kind of async operation means
> that the async thread would have to pull in local copies (in the
> object cache) for any objects under its microscope.
> To avoid this, I've taken a slightly different approach (which might
> not work in all environments), to simply do the require processing
> after the request ends, but in the same thread.
> Obviously this will occupy that thread while its processing, which
> will cause problems in certain scenarios.

Yeah...bringing the objects over for inspection really doesn't bother  
me so much.

I have thought of trying to arrange connection affiliation for  
dispatcher agents, so connections have a higher chance of being able  
to reuse objects, if an agent filters for a particular kind of job,  
but I didn't build that particular bit for 1.0.  Certainly if you have  
a process that is entirely about fulfilling the same kind of jobs then  
you're arranging the same sort of optimization with a bigger hammer.

BTW, if you do try to hook zc.async up in Zope 2, I suspect the  
pertinent configuration section is "Configuration without Zope 3" as  
opposed to "Configuration with Zope 3"...unless Zope 2 drags  
zope.app.appsetup in already, in which case, heck, I dunno, maybe the  
Zope 3 zcml would in fact work.  I'd certainly love to know, and be  
thrilled for the package to be easily usable in Zope 2 also.


More information about the Grok-dev mailing list