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@magma.ca>:
----- Original Message ----- From: "Jan-Ole Esleben" <esleben@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