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 <[EMAIL PROTECTED]>: > > ----- Original Message ----- > From: "Jan-Ole Esleben" <[EMAIL PROTECTED]> > > > > 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 > > > _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )