[Zope] ZASync method calls

[Jan-Ole Esleben]

Thanks for the suggestion; it helped in part:
I can now get it to work basically (the asynchronous job hadn't run at
all in the background, while now - from my own debugging output - I
can see that it does).

However, the instance variable doesn't change until the caller of the
asynchronous method has finished - it _is_ different afterwards
though, it seems like the caller doesn't check for a change; is there
a way to force that?

Ole


2005/8/23, Jonathan <dev101 at magma.ca>:
> 
> ----- Original Message -----
> From: "Jan-Ole Esleben" <esleben at gmail.com>
> >
> > I'm having a really complicated problem that I don't know how to put into
> > words properly, because I'm really vague on what's causing it and the
> > setup is highly involved; I would be _really_ glad if someone could help
> > me
> > out with this:
> >
> > I have a ZOPE instance (connected to a ZEO server) running a custom
> > method call wrapper that decides (based on the method's arguments) to
> > run a method asynchronously using zasync (as well as some other stuff that
> > I think isn't important in the context of my problem). All this has
> > been tested. For various
> > reasons, the method call's path is approximately as follows:
> >
> > 0. Method call using a generic Python method
> > 1. Python code - resolves the method's location and name using ZOPE
> > methods
> > 2. Method dispatcher (called via ZOPE): dispatches synchronously or
> > asynchronously, using zasync, zope_exec and putSessionCall; the method
> > called is again a ZOPE method that calls the final method as another
> > ZOPE method
> >
> > The apparent massive indirection cannot be avoided (for rather complicated
> > reasons). Everything is supposed to be highly generic.
> >
> > My problem is this: if I use a test method that dispatches such an
> > asynchronous
> > method that is supposed to change an instance variable (the class is
> > persistent) and run for ten seconds, then wait for fourteen seconds and
> > see
> > if the method has run (check the instance variable) synchronously (while
> > the
> > asynchronous method is supposed to work in the background), I find the
> > variable unchanged; further checks (using print statements) confirm that
> > the
> > asynchronous method indeed doesn't run until my assertion fails, even if I
> > give
> > it a lot of time.
> >
> > If I disconnect both - run the long running method asynchronously, then
> > run
> > (via ZOPE directly, not from within the same method call) a synchronous
> > method
> > that waits for fourteen seconds and checks the variable, the asynchronous
> > call
> > works just fine (even though both run alongsinde for a time).
> >
> > It isn't the number of threads available to the zserver, I've increased
> > that
> > and nothing has changed. Manual tests of asynchronous methods also don't
> > show
> > anything wrong with my zasync setup. I can only assume that the
> > asynchronous
> > method is _started_ only _after_ the caller has finished. Is there a
> > reason for
> > that, and can I circumvent it? Or am I completely wrong and something else
> > isn't working?
> >
> > I'm on Windows XP SP2, ZOPE 2.7.6, Python 2.3.5 with Twisted installed.
> >
> 
> Is it possible that your asynchronous routine is not committing the
> transaction? ie. If zope considers the async routine to be part of the
> current 'session' then the variable the async routine is updating will not
> be changed until the current session is completed and zope commits the
> transaction (so any checks of the variable during the current session will
> not see any changes to the variable).
> 
> To see if this is the case you could add a "get_transaction().commit()"
> statement in your code after you change the variable's contents.
> 
> hth
> 
> Jonathan
> 
> 
>