Hi, I had to discard a version I was working on in Zope 2.1 twice already because in the normal view there happened a "VersionLockError": Error Type: VersionLockError Error Value: ("'\\000\\000\\000\\000\\000\\000\\005\\341'", 'ArtikelVersion') Traceback (innermost last): File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 179, in publish File /serve/Zope-2.1.0-NR/lib/python/Zope/__init__.py, line 202, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 169, in publish File /serve/Zope-2.1.0-NR/lib/python/ZODB/Transaction.py, line 237, in commit File /serve/Zope-2.1.0-NR/lib/python/ZODB/Connection.py, line 327, in commit (Info: (('*/z19MlDlV7e7P0QHV0lJ5A==', 'AdBanner'), '\000\000\000\000\000\000\005\341', '')) File /serve/Zope-2.1.0-NR/lib/python/ZODB/FileStorage.py, line 614, in store (Object: /serve/Zope-2.1.0-NR/var/Data.fs) VersionLockError: (see above) Is this something known to you? Is this a bug? Does anyone know when this can happen? Are there things to avoid when working in a version? If this happens rather often and unknown to the content manager, I guess the Versions of Zope are rather unusable, because they do not protect your working securly! Regards Jochen
Do you have Zope 2.1.1 ? If not you need it. Jochen Haeberle wrote:
Hi,
I had to discard a version I was working on in Zope 2.1 twice already because in the normal view there happened a "VersionLockError":
Error Type: VersionLockError Error Value: ("'\\000\\000\\000\\000\\000\\000\\005\\341'", 'ArtikelVersion')
Traceback (innermost last): File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 179, in publish File /serve/Zope-2.1.0-NR/lib/python/Zope/__init__.py, line 202, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 169, in publish File /serve/Zope-2.1.0-NR/lib/python/ZODB/Transaction.py, line 237, in commit File /serve/Zope-2.1.0-NR/lib/python/ZODB/Connection.py, line 327, in commit (Info: (('*/z19MlDlV7e7P0QHV0lJ5A==', 'AdBanner'), '\000\000\000\000\000\000\005\341', '')) File /serve/Zope-2.1.0-NR/lib/python/ZODB/FileStorage.py, line 614, in store (Object: /serve/Zope-2.1.0-NR/var/Data.fs) VersionLockError: (see above)
Is this something known to you? Is this a bug? Does anyone know when this can happen? Are there things to avoid when working in a version?
If this happens rather often and unknown to the content manager, I guess the Versions of Zope are rather unusable, because they do not protect your working securly!
Regards
Jochen
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- "One World, one Web, one Program" - Microsoft promotional ad (circa 1995) "Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damage per incident.
Hi, At 13:25 Uhr -0500 19.12.1999, ozric wrote:
Do you have Zope 2.1.1 ? If not you need it.
Oh really? Is this the solution? The instance in question really is a Zope 2.1.0 I'll give it a try! Thanks Jochen
Jochen Haeberle wrote:
Hi,
I had to discard a version I was working on in Zope 2.1 twice already because in the normal view there happened a "VersionLockError":
Error Type: VersionLockError Error Value: ("'\\000\\000\\000\\000\\000\\000\\005\\341'",
'ArtikelVersion')
Jochen Haeberle wrote:
Hi,
I had to discard a version I was working on in Zope 2.1 twice already because in the normal view there happened a "VersionLockError":
Error Type: VersionLockError Error Value: ("'\\000\\000\\000\\000\\000\\000\\005\\341'", 'ArtikelVersion')
Traceback (innermost last): File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 179, in publish File /serve/Zope-2.1.0-NR/lib/python/Zope/__init__.py, line 202, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /serve/Zope-2.1.0-NR/lib/python/ZPublisher/Publish.py, line 169, in publish File /serve/Zope-2.1.0-NR/lib/python/ZODB/Transaction.py, line 237, in commit File /serve/Zope-2.1.0-NR/lib/python/ZODB/Connection.py, line 327, in commit (Info: (('*/z19MlDlV7e7P0QHV0lJ5A==', 'AdBanner'), '\000\000\000\000\000\000\005\341', '')) File /serve/Zope-2.1.0-NR/lib/python/ZODB/FileStorage.py, line 614, in store (Object: /serve/Zope-2.1.0-NR/var/Data.fs) VersionLockError: (see above)
Hm. You should have gotten a more informative error message that said something alomg the line of "this request could not be completed because it modified an object that has been modified in a version".
Is this something known to you?
Yes.
Is this a bug?
No (except for the error message).
Does anyone know when this can happen?
Yes. It happens when you try to modify an an object that has been modified in (another) version. When you modify an object in a version, the object is locked and can only be modified in that version. The effect of a change can be wideer than expected. For example, adding an object to a folder modifies the folder. If changing an object causes a catalog to be updated, then changing an object in a version locks the catalog, as well as the object.
Are there things to avoid when working in a version?
Avoid changing objects you don't want to lock.
If this happens rather often and unknown to the content manager, I guess the Versions of Zope are rather unusable, because they do not protect your working securly!
Perhaps. This is a function of the objects you are working with, Objects that make far flung changes (e.g. objects that modify a central catalog) or objects that make changes in non-management situtations don't work well with versions. Perhaps objects that behave this way should provide some sort of warning when used in a version. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Hi Jim, At 11:49 Uhr +0000 20.12.1999, Jim Fulton wrote:
Hm. You should have gotten a more informative error message that said something alomg the line of "this request could not be completed because it modified an object that has been modified in a version".
Is this something known to you?
Yes.
Is this a bug?
No (except for the error message).
Does anyone know when this can happen?
Yes. It happens when you try to modify an an object that has been modified in (another) version. When you modify an object in a version, the object is locked and can only be modified in that version. The effect of a change can be wideer than expected. For example, adding an object to a folder modifies the folder. If changing an object causes a catalog to be updated, then changing an object in a version locks the catalog, as well as the object.
Mhm, not really. Only if you refer to the non Version environment as a a Version, too (what you probably do), well, then it is probably the catalog messing up... But then, it is a real pain... how am I supposed to work on features in a version if I can't try it using the catalog...
Are there things to avoid when working in a version?
Avoid changing objects you don't want to lock.
:-) How to in a system that autoupdates the catalog???
If this happens rather often and unknown to the content manager, I guess the Versions of Zope are rather unusable, because they do not protect your working securly!
Perhaps. This is a function of the objects you are working with, Objects that make far flung changes (e.g. objects that modify a central catalog) or objects that make changes in non-management situtations don't work well with versions. Perhaps objects that behave this way should provide some sort of warning when used in a version.
Yes, that's true. Thanks for your detailed answer, but unfortunately you left me with a big questionmark on my face :-( Jochen
Jochen Haeberle wrote:
(snip)
Yes. It happens when you try to modify an an object that has been modified in (another) version. When you modify an object in a version, the object is locked and can only be modified in that version. The effect of a change can be wideer than expected. For example, adding an object to a folder modifies the folder. If changing an object causes a catalog to be updated, then changing an object in a version locks the catalog, as well as the object.
Mhm, not really. Only if you refer to the non Version environment as a a Version, too (what you probably do), well, then it is probably the catalog messing up...
But then, it is a real pain... how am I supposed to work on features in a version if I can't try it using the catalog...
This is currently an issue that limits the usefulness of using versions and catalog together. It is a situation that we plan to improve. :) There are a number of things we can do to address this: 1. Reduce the number of updates made when an object is added to the catalog. For example, there is a problem with the current BTree implementation that causes too many nodes to get updated due to the way that tree-size information is stored in intermediate nodes. We are working on fixing this. 2. Add a ZODB conflict-resolution protocol. This will allow application level code to resolve conflicts. For example, imagine two requests that add items to a folder with different names. Currently, these requests conflict because they both modify the folder. In the future, folders might implement methods that resolve the conflict by adding both items. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
2. Add a ZODB conflict-resolution protocol. This will allow application level code to resolve conflicts. For example, imagine two requests that add items to a folder with different names. Currently, these requests conflict because they both modify the folder. In the future, folders might implement methods that resolve the conflict by adding both items.
Ooooh.. I would definitely like to see this happen. Have a timeline in mind? :) --Adam
participants (4)
-
Jim Fulton -
Jochen Haeberle -
M. Adam Kendall -
ozric