Hi all I've got some pages in my Zope application that display results of SQL query (results returned by Z-SQL Method) and check for existence of some data in SESSION object. There is nothing more on the pages but one thing - pages are refreshed every 30 seconds. I also have some users (really not many) that constantly monitor these pages. The last thing I've got is some error messages. The error message that displays on page looks like: An error was encountered while publishing this resource. ZODB.POSException.ConflictError Sorry, a site error occurred. Traceback (innermost last): ° Module ZPublisher.Publish, line 150, in publish_module ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 122, in publish ° Module Zope.App.startup, line 142, in zpublisher_exception_hook ° Module ZPublisher.Publish, line 102, in publish ° Module Zope.App.startup, line 200, in commit ° Module ZODB.Transaction, line 235, in commit ° Module ZODB.Transaction, line 349, in _commit_objects ° Module ZODB.Connection, line 391, in commit ° __traceback_info__: (('BTrees.OOBTree', 'OOBTree'), '\x00\x00\x00\x00\x00\x00\x01\xcd', '') ° Module Products.TemporaryFolder.TemporaryStorage, line 134, in store ConflictError: database conflict error (oid 00000000000001cd, serial was 034b62206010624c, now 034b621e679953b3) This error usually disappears after refreshing the page (but confuses the users). Some of error messages that are logged in my "stupid" log: 2003-03-06T09:50:36 INFO(0) ZODB conflict error at /ctt/cmp/info/yesterday/midday/index_html (138 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:29 INFO(0) ZODB conflict error at /ctt/firm/props (139 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:39 INFO(0) ZODB conflict error at /ctt/firm/props (140 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:49 INFO(0) ZODB conflict error at /ctt/firm/index_html (141 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:53:08 INFO(0) ZODB conflict error at /ctt/cmp/info/yesterday/index_html (142 conflicts since startup at 2003-03-05T16:20:08) I have searched mailing lists, but I didn't find the answer for the question - what's going on? and what interests me most: what to do with this? I've found some sugestions that such errors called read conflicts may be caused by using the session. Is that true? Why the session? I don't think that I can stop using session object. Any more suggestions? Any solutions? There must be any simple solution - my app has only few users! Thanks -- Jakub Wisniowski
On Thursday 06 March 2003 11:30, Jakub Wisniowski wrote:
Hi all
I've got some pages in my Zope application that display results of SQL query (results returned by Z-SQL Method) and check for existence of some data in SESSION object. There is nothing more on the pages but one thing - pages are refreshed every 30 seconds. I also have some users (really not many) that constantly monitor these pages. The last thing I've got is some error messages. The error message that displays on page looks like:
An error was encountered while publishing this resource. ZODB.POSException.ConflictError Sorry, a site error occurred. Traceback (innermost last): ° Module ZPublisher.Publish, line 150, in publish_module ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 127, in publish ° Module ZPublisher.Publish, line 122, in publish ° Module Zope.App.startup, line 142, in zpublisher_exception_hook ° Module ZPublisher.Publish, line 102, in publish ° Module Zope.App.startup, line 200, in commit ° Module ZODB.Transaction, line 235, in commit ° Module ZODB.Transaction, line 349, in _commit_objects ° Module ZODB.Connection, line 391, in commit ° __traceback_info__: (('BTrees.OOBTree', 'OOBTree'), '\x00\x00\x00\x00\x00\x00\x01\xcd', '') ° Module Products.TemporaryFolder.TemporaryStorage, line 134, in store ConflictError: database conflict error (oid 00000000000001cd, serial was 034b62206010624c, now 034b621e679953b3)
This error usually disappears after refreshing the page (but confuses the users). Some of error messages that are logged in my "stupid" log:
2003-03-06T09:50:36 INFO(0) ZODB conflict error at /ctt/cmp/info/yesterday/midday/index_html (138 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:29 INFO(0) ZODB conflict error at /ctt/firm/props (139 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:39 INFO(0) ZODB conflict error at /ctt/firm/props (140 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:52:49 INFO(0) ZODB conflict error at /ctt/firm/index_html (141 conflicts since startup at 2003-03-05T16:20:08) ------ 2003-03-06T09:53:08 INFO(0) ZODB conflict error at /ctt/cmp/info/yesterday/index_html (142 conflicts since startup at 2003-03-05T16:20:08)
I have searched mailing lists, but I didn't find the answer for the question - what's going on? and what interests me most: what to do with this? I've found some sugestions that such errors called read conflicts may be caused by using the session. Is that true? Why the session? I don't think that I can stop using session object. Any more suggestions? Any solutions? There must be any simple solution - my app has only few users!
I already had same kind of problem while "storing" Zope persistent objects into SESSION. Problem disappeared when switching SESSION informations to simple Python objects (strings, lists,...). Thierry -- Linux every day, keeps Dr Watson away... http://gpc.sourceforge.net -- http://www.ulthar.net
Thursday, March 6, 2003, 11:40:21 AM, you wrote: TF> I already had same kind of problem while "storing" Zope persistent objects TF> into SESSION. TF> Problem disappeared when switching SESSION informations to simple Python TF> objects (strings, lists,...). TF> Thierry Thanks for reply. My SESSION holds only Python dictionary with logged user's data. Is it checked on every page to let me know if the user has been logged in. Maybe I should switch from a dictionary to a list? Sounds rather strange... One more info - my Zope's version is 2.6.1. -- Jakub Wisniowski
Jakub Wisniowski wrote at 2003-3-6 12:03 +0100:
Thanks for reply. My SESSION holds only Python dictionary with logged user's data. Is it checked on every page to let me know if the user has been logged in. Maybe I should switch from a dictionary to a list? Sounds rather strange... One more info - my Zope's version is 2.6.1.
This is not your problem.... You can stick with dictionaries. When you use objects that are itself persistent, then you can reduce the conflict probability, however, the conflict probably happens already on the main session object (updating its "last accessed time"). If this were true, then "application level conflict resolution" (Howto on Zope.org) might help. Dieter
Jakub Wisniowski wrote at 2003-3-6 11:30 +0100:
.... An error was encountered while publishing this resource. ZODB.POSException.ConflictError .... ° __traceback_info__: (('BTrees.OOBTree', 'OOBTree'), '\x00\x00\x00\x00\x00\x00\x01\xcd', '') ° Module Products.TemporaryFolder.TemporaryStorage, line 134, in store ConflictError: database conflict error (oid 00000000000001cd, serial was 034b62206010624c, now 034b621e679953b3)
A search over the mailing list archives (for "ConflictError") will show hundreds of messages related to your problem.... Probably, several requests try to modify the same session related object at the same time. Due to peculiarities of the session implementation, a read access to a session causes writing as well. Reduce the amount of session access to the cases when you really need it. Especially, try not to access the session in all frames of a frameset... Occasional conflicts are unavoidable and should not harm (as requests are automatically retried).
This error usually disappears after refreshing the page (but confuses the users).
That's strnage. The user should get such a page only when conflicts happen with very high frequency (the request is retried 2 or 3 times before it fails). Dieter
participants (3)
-
Dieter Maurer -
Jakub Wisniowski -
Thierry FLORAC