[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.
Gary
More information about the Grok-dev
mailing list