I am experiencing a problem with my Zope application, interfacing with PostgreSQL through PsycopDA. The problem is basically that a python script creates a new record in a database table, which is used by exUserFolder as a backend for authentication (thus containing the list of all users). When this completes, the script calls another script which tries to change ownership of a ZoDB object to the newly created user, which fails because "Only users in this site can be made owners." I think the problem is rooted in the fact that python scripts work on databases in transaction batches, and as the script has not finished, the transaction adding the user has not been committed. Other than issuing a manual COMMIT, how can I make sure that exUserFolder sees the changes made to a database while the script is still executing? Thanks, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! "frank harris has been received in all the great houses -- once!" -- oscar wilde
martin f krafft wrote at 2004-3-14 07:32 +0100:
I am experiencing a problem with my Zope application, interfacing with PostgreSQL through PsycopDA. The problem is basically that a python script creates a new record in a database table, which is used by exUserFolder as a backend for authentication (thus containing the list of all users). When this completes, the script calls another script which tries to change ownership of a ZoDB object to the newly created user, which fails because
"Only users in this site can be made owners."
I think the problem is rooted in the fact that python scripts work on databases in transaction batches, and as the script has not finished, the transaction adding the user has not been committed.
Other than issuing a manual COMMIT, how can I make sure that exUserFolder sees the changes made to a database while the script is still executing?
One way to esure that things are done would be to redirect after the database modification (i.e. make a new request). -- Dieter
also sprach Dieter Maurer <dieter@handshake.de> [2004.03.14.2127 +0100]:
One way to esure that things are done would be to redirect after the database modification (i.e. make a new request).
Unfortunately, I have to pass around a lot of data, and the data may be larger than 4Kb, so I could only do a POST request, which is not really easy to do from a script... -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! always remember you're unique, just like everyone else.
are the script and the userfolder using the same DA, if their not then they are using different database connections and transaction isolation is causing your problem. -kapil On Sun, 2004-03-14 at 01:32, martin f krafft wrote:
I am experiencing a problem with my Zope application, interfacing with PostgreSQL through PsycopDA. The problem is basically that a python script creates a new record in a database table, which is used by exUserFolder as a backend for authentication (thus containing the list of all users). When this completes, the script calls another script which tries to change ownership of a ZoDB object to the newly created user, which fails because
"Only users in this site can be made owners."
I think the problem is rooted in the fact that python scripts work on databases in transaction batches, and as the script has not finished, the transaction adding the user has not been committed.
Other than issuing a manual COMMIT, how can I make sure that exUserFolder sees the changes made to a database while the script is still executing?
Thanks,
also sprach Kapil Thangavelu <hazmat@objectrealms.net> [2004.03.15.0319 +0100]:
are the script and the userfolder using the same DA, if their not then they are using different database connections and transaction isolation is causing your problem.
Yes, they are using the same DA, which is of type PsycopgDA, version 1.1.10-1.1 (Debian). -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! "in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat." -- leon trotsky, 1937
thats odd then, i would check with another python script/zsql method if you can access the record inserted as a sanity check. zsql methods are integrated into zope's txn machinery and thus will only commit on the rdb at the end of the transaction (ie no batching involved). i might suspect some sort of internal caching within xuf, if the second python script/zsql method is able to access the record. possibly (unlikely) this could be an artifact of zpsycopg's own txn isolation settings, another thing to try would be to switch from serialized (default) to read committed. hth, -kapil On Mon, 2004-03-15 at 00:36, martin f krafft wrote:
also sprach Kapil Thangavelu <hazmat@objectrealms.net> [2004.03.15.0319 +0100]:
are the script and the userfolder using the same DA, if their not then they are using different database connections and transaction isolation is causing your problem.
Yes, they are using the same DA, which is of type PsycopgDA, version 1.1.10-1.1 (Debian).
also sprach Kapil Thangavelu <hazmat@objectrealms.net> [2004.03.15.0858 +0100]:
thats odd then, i would check with another python script/zsql method if you can access the record inserted as a sanity check.
i did that, and the record is indeed present.
i might suspect some sort of internal caching within xuf, if the second python script/zsql method is able to access the record.
good thinking. i had "Credential Cache Timeout in Seconds" set to 900 in xuf, but please also keep in mind that I am calling updateUser on the acl_users.currentAuthSource, which invalidates the cache with respect to that user. Here's the code: context.sql.create_user( login=username, [...] ) passwd = REQUEST.form['password'] context.acl_users.currentAuthSource.updateUser(username, passwd, ['Member']) profiles = container.aq_parent.aq_parent.community.profiles profiles.invokeFactory(id=username, type_name='Profile Folder') mt = context.portal_membership context.plone_utils.changeOwnershipOf(obj, username, 0) mt.setLocalRoles(obj=obj, member_ids=(username,), member_role='Owner') Anyway, I set the cache to 0 (No caching), but the problem persists.
possibly (unlikely) this could be an artifact of zpsycopg's own txn isolation settings, another thing to try would be to switch from serialized (default) to read committed.
I am afraid I can't seem to find a setting for this. How would I make the database connection use a different isolation level? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! "alle vorurteile kommen aus den eingeweiden." - friedrich nietzsche
at this point i would try debugging the problem w/ pdb, insert a pdb statement somewhere in the exUserFolder auth source that corresponds to the method that does the auth check. there is some howto material on zope.org on using the debugger. as for the isolation level, i don't know off hand, a quick source inspection doesn't make it apparent either. i saw ref to this on the init.d pyscopg list, and i would suggest asking there. its a question of calling set_isolation_level on the connection object if you want to hack the source. -kapil On Mon, 2004-03-15 at 03:24, martin f krafft wrote:
also sprach Kapil Thangavelu <hazmat@objectrealms.net> [2004.03.15.0858 +0100]:
thats odd then, i would check with another python script/zsql method if you can access the record inserted as a sanity check.
i did that, and the record is indeed present.
i might suspect some sort of internal caching within xuf, if the second python script/zsql method is able to access the record.
good thinking. i had "Credential Cache Timeout in Seconds" set to 900 in xuf, but please also keep in mind that I am calling updateUser on the acl_users.currentAuthSource, which invalidates the cache with respect to that user.
Here's the code:
context.sql.create_user( login=username, [...] )
passwd = REQUEST.form['password'] context.acl_users.currentAuthSource.updateUser(username, passwd, ['Member'])
profiles = container.aq_parent.aq_parent.community.profiles profiles.invokeFactory(id=username, type_name='Profile Folder')
mt = context.portal_membership context.plone_utils.changeOwnershipOf(obj, username, 0) mt.setLocalRoles(obj=obj, member_ids=(username,), member_role='Owner')
Anyway, I set the cache to 0 (No caching), but the problem persists.
possibly (unlikely) this could be an artifact of zpsycopg's own txn isolation settings, another thing to try would be to switch from serialized (default) to read committed.
I am afraid I can't seem to find a setting for this. How would I make the database connection use a different isolation level?
participants (3)
-
Dieter Maurer -
Kapil Thangavelu -
martin f krafft