RE: [Zope] ZODB conflict error AFTER adding an 'Access Rules'
After patching the startup script, I obtain the following details in my errors: 2003-09-16T09:01:01 INFO(0) ZODB conflict error at /ploneroot/resdir/share/ js/share.js: database conflict error (oid 0000000000000011, serial was 034fb0850 4d47222, now 034fb084adf5e580)(1 conflicts since startup at 2003-09-16T08:57:45) ------ 2003-09-16T09:01:02 PROBLEM(100) Localizer The thread number 1928 don't has a re quest object associated. ------ 2003-09-16T09:01:21 INFO(0) ZODB conflict error at /ploneroot/linkTransparent .gif: database conflict error (oid 0000000000000012, serial was 034fb0855b17e4b3 , now 034fb08504d47222)(2 conflicts since startup at 2003-09-16T08:57:45) ------ 2003-09-16T09:01:24 PROBLEM(100) Localizer The thread number 1924 don't has a re quest object associated. I couldn't figure whether it's a read or write conflict,... Does that help? -- Jean
Jean Baltus wrote at 2003-9-16 09:04 +0200:
After patching the startup script, I obtain the following details in my errors:
2003-09-16T09:01:01 INFO(0) ZODB conflict error at /ploneroot/resdir/share/ js/share.js: database conflict error (oid 0000000000000011, serial was 034fb0850 4d47222, now 034fb084adf5e580)(1 conflicts since startup at 2003-09-16T08:57:45)
------ 2003-09-16T09:01:02 PROBLEM(100) Localizer The thread number 1928 don't has a re quest object associated. ------ 2003-09-16T09:01:21 INFO(0) ZODB conflict error at /ploneroot/linkTransparent .gif: database conflict error (oid 0000000000000012, serial was 034fb0855b17e4b3 , now 034fb08504d47222)(2 conflicts since startup at 2003-09-16T08:57:45) ------ 2003-09-16T09:01:24 PROBLEM(100) Localizer The thread number 1924 don't has a re quest object associated.
I couldn't figure whether it's a read or write conflict,...
What you see are write conflicts affecting oid 0x11 and 0x12, respectively. Read conflicts are reported as "database read conflict error". Usually, Zope can tell you the oid and the class of the affected object for read conflicts. Dieter
Hi again, Thank you for your explanation Dieter. Do you have any clue why I'm having write conflicts when I add a call to the "change_skin" method in the "Access Rule" of our Plone site !!! ??? Even when we just browse the website, no update being made... Is it possibly that it is a bug in CMF? In Zope? In the ZODB? Regards, -- Jean -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: mercredi 17 septembre 2003 19:18 To: Jean Baltus Cc: zope@zope.org Subject: RE: [Zope] ZODB conflict error AFTER adding an 'Access Rules' Jean Baltus wrote at 2003-9-16 09:04 +0200:
After patching the startup script, I obtain the following details in my errors:
2003-09-16T09:01:01 INFO(0) ZODB conflict error at /ploneroot/resdir/share/ js/share.js: database conflict error (oid 0000000000000011, serial was 034fb0850 4d47222, now 034fb084adf5e580)(1 conflicts since startup at 2003-09-16T08:57:45)
------ 2003-09-16T09:01:02 PROBLEM(100) Localizer The thread number 1928 don't has a re quest object associated. ------ 2003-09-16T09:01:21 INFO(0) ZODB conflict error at /ploneroot/linkTransparent .gif: database conflict error (oid 0000000000000012, serial was 034fb0855b17e4b3 , now 034fb08504d47222)(2 conflicts since startup at 2003-09-16T08:57:45) ------ 2003-09-16T09:01:24 PROBLEM(100) Localizer The thread number 1924 don't has a re quest object associated.
I couldn't figure whether it's a read or write conflict,...
What you see are write conflicts affecting oid 0x11 and 0x12, respectively. Read conflicts are reported as "database read conflict error". Usually, Zope can tell you the oid and the class of the affected object for read conflicts. Dieter
Jean Baltus wrote at 2003-9-24 12:07 +0200:
Thank you for your explanation Dieter. Do you have any clue why I'm having write conflicts when I add a call to the "change_skin" method in the "Access Rule" of our Plone site !!! ??? Even when we just browse the website, no update being made...
Often, write conflicts are caused by using a session. Reading a session causes a write (to update the timeout mechanism).
Is it possibly that it is a bug in CMF? In Zope? In the ZODB?
It is of course possible. But I do not yet think it is likely, because I see few complaint about conflict errors when using Zope/CMF. E.g. we use it extensively and do not see this problem (and we use AccessRules, too). You can find out what the object with an oid is: Read about how to inspect ZODB objects in an interactive interpreter (you may need to add "PYTHONPATH" and stop Zope (or use ZEO)). In the interactive interpreter do: from Zope import app from ZODB.utils import p64 R= app() # the root object c= R._p_jar # the main ZODB connection o= c[p64(oid_as_hex)] # the object with oid "oid_as_hex" print o In your case: "o= c[p64(0x11)]" This assumes, the conflict occured within the main ZODB. Sessions use there own ZODB (and therefore a ZODB connection different from that of the root) and store their session objects in RAM. Therefore, it is not possible to inspect the session objects in a separate process. You would need to use the Zope "monitor" to inspect a running Zope itself. There is a HowTo (very old; the monitor is nowadays no longer enabled by default) on Zope.org. Inside the "monitor" client, you can use Python to inspect your running Python as shown above. Inspecting session object with oid "0x11" would look like: from Zope import app from ZODB.utils import p64 R= app() # the root object tf= R.temp_folder # the temporary folder c= tf._p_jar # the ZODB connection used by sessions o= c[p64(oid_as_hex)] # the object with oid "oid_as_hex" print o
...
js/share.js: database conflict error (oid 0000000000000011, serial was 034fb0850
Dieter
Thank you for all the explanation. I don't have time to put on my swimsuit and dive into the ZODB today but I will... In the meantime, here is the exact copy of my access rule (in case you notice something weird): session = context.REQUEST.SESSION path_info = context.REQUEST['PATH_INFO'] if not session.has_key('skin'): session.set('skin', 'bidon') if path_info.find("/muse") >=0: session.set('skin', 'muse') elif path_info.find("/res") >=0: session.set('skin', 'res') if session['skin']== 'res': context.changeSkin('res') The script updates the 'skin' attribute of 'session' each time it traverses the 'muse' or 'res' directory of our website. Then the changeSkin method is called whenever we are in the 'res' part of the website. If you ever see something wrong with it, please tell me, THANKS !!! -- Jean -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: jeudi 25 septembre 2003 2:17 To: Jean Baltus Cc: zope@zope.org Subject: RE: [Zope] ZODB conflict error AFTER adding an 'Access Rules' Jean Baltus wrote at 2003-9-24 12:07 +0200:
Thank you for your explanation Dieter. Do you have any clue why I'm having write conflicts when I add a call to the "change_skin" method in the "Access Rule" of our Plone site !!! ??? Even when we just browse the website, no update being made...
Often, write conflicts are caused by using a session. Reading a session causes a write (to update the timeout mechanism).
Is it possibly that it is a bug in CMF? In Zope? In the ZODB?
It is of course possible. But I do not yet think it is likely, because I see few complaint about conflict errors when using Zope/CMF. E.g. we use it extensively and do not see this problem (and we use AccessRules, too). You can find out what the object with an oid is: Read about how to inspect ZODB objects in an interactive interpreter (you may need to add "PYTHONPATH" and stop Zope (or use ZEO)). In the interactive interpreter do: from Zope import app from ZODB.utils import p64 R= app() # the root object c= R._p_jar # the main ZODB connection o= c[p64(oid_as_hex)] # the object with oid "oid_as_hex" print o In your case: "o= c[p64(0x11)]" This assumes, the conflict occured within the main ZODB. Sessions use there own ZODB (and therefore a ZODB connection different from that of the root) and store their session objects in RAM. Therefore, it is not possible to inspect the session objects in a separate process. You would need to use the Zope "monitor" to inspect a running Zope itself. There is a HowTo (very old; the monitor is nowadays no longer enabled by default) on Zope.org. Inside the "monitor" client, you can use Python to inspect your running Python as shown above. Inspecting session object with oid "0x11" would look like: from Zope import app from ZODB.utils import p64 R= app() # the root object tf= R.temp_folder # the temporary folder c= tf._p_jar # the ZODB connection used by sessions o= c[p64(oid_as_hex)] # the object with oid "oid_as_hex" print o
...
js/share.js: database conflict error (oid 0000000000000011, serial was 034fb0850
Dieter
Jean Baltus wrote at 2003-9-25 16:22 +0200:
I don't have time to put on my swimsuit and dive into the ZODB today but I will...
In the meantime, here is the exact copy of my access rule (in case you notice something weird):
session = context.REQUEST.SESSION path_info = context.REQUEST['PATH_INFO']
if not session.has_key('skin'): session.set('skin', 'bidon')
if path_info.find("/muse") >=0: session.set('skin', 'muse') elif path_info.find("/res") >=0: session.set('skin', 'res')
if session['skin']== 'res': context.changeSkin('res')
Thus, you read and write "session". Almost surely, this is the cause of your "ConflictError"s. Session related conflicts are especially likely when you use a frame based UI (as all frames in a frameset make requests at the same time and are likely to access the same session object). Occational "ConflictError"s are harmless. You can ignore them. Dieter
On Friday, September 26, 2003, at 05:10 AM, Dieter Maurer wrote:
Jean Baltus wrote at 2003-9-25 16:22 +0200:
I don't have time to put on my swimsuit and dive into the ZODB today but I will...
In the meantime, here is the exact copy of my access rule (in case you notice something weird):
session = context.REQUEST.SESSION path_info = context.REQUEST['PATH_INFO']
if not session.has_key('skin'): session.set('skin', 'bidon')
if path_info.find("/muse") >=0: session.set('skin', 'muse') elif path_info.find("/res") >=0: session.set('skin', 'res')
if session['skin']== 'res': context.changeSkin('res')
Thus, you read and write "session". Almost surely, this is the cause of your "ConflictError"s.
Yup. Jean, try to avoid needless writes to the session object. For example throw some conditional code in your access rule of the form: if session.get(key) != value: session.set(key,value) That should help reduce the number of "ConflictError"s. Michael
Michael Dunstan wrote at 2003-9-26 11:34 +1200:
... Jean, try to avoid needless writes to the session object. For example throw some conditional code in your access rule of the form:
if session.get(key) != value: session.set(key,value)
That should help reduce the number of "ConflictError"s.
Note, however, that reading the session writes it (in order to update the expiration deadline). Dieter
On Saturday, September 27, 2003, at 05:01 AM, Dieter Maurer wrote:
Michael Dunstan wrote at 2003-9-26 11:34 +1200:
... Jean, try to avoid needless writes to the session object. For example throw some conditional code in your access rule of the form:
if session.get(key) != value: session.set(key,value)
That should help reduce the number of "ConflictError"s.
Note, however, that reading the session writes it (in order to update the expiration deadline).
I figured that there is some kind of filtering for updating the expiration deadline. The filtering reduces excessive writes at the expense of the accuracy of the deadline. Michael
Michael Dunstan wrote at 2003-9-27 11:35 +1200:
On Saturday, September 27, 2003, at 05:01 AM, Dieter Maurer wrote:
Note, however, that reading the session writes it (in order to update the expiration deadline).
I figured that there is some kind of filtering for updating the expiration deadline. The filtering reduces excessive writes at the expense of the accuracy of the deadline.
An interesting idea! This way, one could indeed reduce writing frequency. I am not sure whether it is implemented by Transience". Dieter
participants (4)
-
Chris Withers -
Dieter Maurer -
Jean Baltus -
Michael Dunstan