ConflictError on intSet after 2.6 migration breaks squishdot (ZCatalog):
Hi All After upgrading to Zope 2.6.0 (from 2.3.3 - 2.4.4), I found the following error in my stupid.log 2003-01-30T18:53:44 ERROR(200) Zope Couldn't install OFSP Traceback (innermost last): Module OFS.Application, line 700, in install_product - __traceback_info__: OFSP Module ZODB.Transaction, line 222, in commit Module ZODB.Transaction, line 195, in commit Module ZODB.Transaction, line 256, in _commit_objects Module ZODB.Connection, line 389, in commit - __traceback_info__: (('intSet', 'intSet'), '\x00\x00\x00\x00\x00\x00\x05x', '') Module ZODB.FileStorage, line 705, in store ConflictError: database conflict error (oid 0000000000000578, serial was 034a18174c3503ee, now 0000000000000000) ------ 2003-01-30T18:53:44 PROBLEM(100) Zope No such file or directory: /var/Zope/instances/cc26/Products/PlugIns/help ------ 2003-01-30T18:53:44 ERROR(200) Zope Couldn't install ZCatalog Traceback (innermost last): Module OFS.Application, line 700, in install_product - __traceback_info__: ZCatalog Module ZODB.Transaction, line 222, in commit Module ZODB.Transaction, line 195, in commit Module ZODB.Transaction, line 256, in _commit_objects Module ZODB.Connection, line 389, in commit - __traceback_info__: (('intSet', 'intSet'), '\x00\x00\x00\x00\x00\x00\x07\x8b', '') Module ZODB.FileStorage, line 705, in store ConflictError: database conflict error (oid 000000000000078b, serial was 034a1817514f2bb3, now 0000000000000000) I've already found out that explicitly deleting ZCatalog and OFSP from /Control_Panel/Products fixes these startup errors (they're not ZClass products, and come back after a restart). However, we're currently upgrading squishdot as well, and now we get the same exception each time when adding a new post (probably due to ZCatalog updates) - the posts aren't added, of course Module ZODB.Transaction, line 256, in _commit_objects Module ZODB.Connection, line 389, in commit __traceback_info__: (('intSet', 'intSet'), '\x00\x00\x00\x00\x00\x16\xf2\xd1', '') Module ZODB.FileStorage, line 705, in store ConflictError: database conflict error (oid 000000000016f2d1, serial was 034976c696679466, now 0000000000000000) So, what's going on here? Does anyone know how to fix this? It breaks squishdot beyond repair at this moment, and we need Zope 2.6 for it's improved memory management. -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- T +31-20-4688336 F +31-20-4688337 Linux/Web/Zope/SQL/MMBase W http://www.amaze.nl E info@amaze.nl Network Solutions W http://vanderwijk.info E ivo@amaze.nl Consultancy PGP http://vanderwijk.info/pgp -=-
On Friday 31 January 2003 10:47 am, Ivo van der Wijk wrote:
However, we're currently upgrading squishdot as well, and now we get the same exception each time when adding a new post (probably due to ZCatalog updates) - the posts aren't added, of course
Module ZODB.Transaction, line 256, in _commit_objects Module ZODB.Connection, line 389, in commit __traceback_info__: (('intSet', 'intSet'), '\x00\x00\x00\x00\x00\x16\xf2\xd1', '') Module ZODB.FileStorage, line 705, in store
ConflictError: database conflict error (oid 000000000016f2d1, serial was 034976c696679466, now 0000000000000000)
That all-zeroes serial is very odd. I dont think that should ever happen. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On Fri, Jan 31, 2003 at 11:21:57AM +0000, Toby Dickenson wrote:
On Friday 31 January 2003 10:47 am, Ivo van der Wijk wrote:
However, we're currently upgrading squishdot as well, and now we get the same exception each time when adding a new post (probably due to ZCatalog updates) - the posts aren't added, of course
Module ZODB.Transaction, line 256, in _commit_objects Module ZODB.Connection, line 389, in commit __traceback_info__: (('intSet', 'intSet'), '\x00\x00\x00\x00\x00\x16\xf2\xd1', '') Module ZODB.FileStorage, line 705, in store
ConflictError: database conflict error (oid 000000000016f2d1, serial was 034976c696679466, now 0000000000000000)
That all-zeroes serial is very odd. I dont think that should ever happen.
I'm not too familiar with this stuff but this is what I think happens: Squisdot uses an intSet internally for storing article numbers, and a standard object hierarchie to store the actual data. Upon unpersisting the intSet (als in ZCatalogs), no errors occur, but the correct data is not restored in the object. Persisting/comitting an intSet does create a conflict, perhaps because of the improper unpersisting. This explains why, for example, we get tons of keyerrors on intSets when trying to update the Squisdhot catalog. I don't know if I make any sense here - it's just the way I interpret the problems I encountered. Cheers Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- T +31-20-4688336 F +31-20-4688337 Linux/Web/Zope/SQL/MMBase W http://www.amaze.nl E info@amaze.nl Network Solutions W http://vanderwijk.info E ivo@amaze.nl Consultancy PGP http://vanderwijk.info/pgp -=-
participants (2)
-
Ivo van der Wijk -
Toby Dickenson