----- 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
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
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
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
method that is supposed to change an instance variable (the class is
persistent) and run for ten seconds, then wait for fourteen seconds and
if the method has run (check the instance variable) synchronously (while
asynchronous method is supposed to work in the background), I find the
variable unchanged; further checks (using print statements) confirm that
asynchronous method indeed doesn't run until my assertion fails, even if I
it a lot of time.
If I disconnect both - run the long running method asynchronously, then
(via ZOPE directly, not from within the same method call) a synchronous
that waits for fourteen seconds and checks the variable, the asynchronous
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
and nothing has changed. Manual tests of asynchronous methods also don't
anything wrong with my zasync setup. I can only assume that the
method is _started_ only _after_ the caller has finished. Is there a
that, and can I circumvent it? Or am I completely wrong and something else
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 -