----- 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.



Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to