_p_resolveConflict not called on conflict
Hi, I have a class CourseResults, where I defined: def _p_resolveConflict(self, oldstate, committed, newstate): # Apply the changes made in going from old to newstate to # committed import pdb;pdb.set_trace() in my log I see: 2007-08-07 16:26:14 INFO ZPublisher.Conflict ConflictError at /uniben/campus/students/U315204/study_course/create_level: database conflict error (oid 0x37fc36, class Products.WAeUP_SRP.WAeUPTables.CourseResults, serial this txn started with 0x036f83420cc02caa 2007-08-07 14:26:02.988441, serial currently committed 0x036f834237c65b99 2007-08-07 14:26:13.072227) (1 conflicts (0 unresolved) since startup at Tue Aug 7 16:15:17 2007) but _p_resolveConflict is not invoked. what do I do wrong ? -- Gruß Joachim
--On 7. August 2007 16:40:36 +0200 Joachim Schmitz <js@aixtraware.de> wrote:
Hi,
I have a class CourseResults, where I defined:
def _p_resolveConflict(self, oldstate, committed, newstate): # Apply the changes made in going from old to newstate to # committed import pdb;pdb.set_trace()
in my log I see:
2007-08-07 16:26:14 INFO ZPublisher.Conflict ConflictError at /uniben/campus/students/U315204/study_course/create_level: database conflict error (oid 0x37fc36, class Products.WAeUP_SRP.WAeUPTables.CourseResults, serial this txn started with 0x036f83420cc02caa 2007-08-07 14:26:02.988441, serial currently committed 0x036f834237c65b99 2007-08-07 14:26:13.072227) (1 conflicts (0 unresolved) since startup at Tue Aug 7 16:15:17 2007)
No idea but you might try to pdb in ZODB/Connection.py where the _p_resovleConflict() handle is called (if available). -aj
On 8/7/07, Joachim Schmitz <js@aixtraware.de> wrote:
but _p_resolveConflict is not invoked.
what do I do wrong ?
Is ZEO involved? If so, does your ZEO instance have the Product installed (with all it's dependencies), so the ZEO server can access the resolve method? -- Martijn Pieters
--On 7. August 2007 18:40:25 +0200 Martijn Pieters <mj@zopatista.com> wrote:
On 8/7/07, Joachim Schmitz <js@aixtraware.de> wrote:
but _p_resolveConflict is not invoked.
what do I do wrong ?
Is ZEO involved? If so, does your ZEO instance have the Product installed (with all it's dependencies), so the ZEO server can access the resolve method?
Are you sure that conflict resolution happens on the ZEO server side? -aj
On 8/7/07, Andreas Jung <lists@zopyx.com> wrote:
Is ZEO involved? If so, does your ZEO instance have the Product installed (with all it's dependencies), so the ZEO server can access the resolve method?
Are you sure that conflict resolution happens on the ZEO server side?
Absolutely. Where else would it happen? -- Martijn Pieters
On 8/7/07, Martijn Pieters <mj@zopatista.com> wrote:
On 8/7/07, Andreas Jung <lists@zopyx.com> wrote:
Is ZEO involved? If so, does your ZEO instance have the Product installed (with all it's dependencies), so the ZEO server can access the resolve method?
Are you sure that conflict resolution happens on the ZEO server side?
Absolutely. Where else would it happen?
See the "Caveats and Dangers" section in: http://svn.zope.org/ZODB/trunk/src/ZODB/ConflictResolution.txt?rev=77078&vie... Conflict Resolution is a feature of a ZODB storage, and as the storage is the responsibility of the ZEO server, takes place there. -- Martijn Pieters
Martijn Pieters wrote:
See the "Caveats and Dangers" section in:
http://svn.zope.org/ZODB/trunk/src/ZODB/ConflictResolution.txt?rev=77078&vie...
Conflict Resolution is a feature of a ZODB storage, and as the storage is the responsibility of the ZEO server, takes place there.
We, not quite, I suspect ;-) If the conflict occurs between two threads on one app server, then I would expect conflict resolution to happen on the app server and not the storage... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Martijn Pieters wrote:
See the "Caveats and Dangers" section in:
http://svn.zope.org/ZODB/trunk/src/ZODB/ConflictResolution.txt?rev=77078&vie...
Conflict Resolution is a feature of a ZODB storage, and as the storage is the responsibility of the ZEO server, takes place there.
We, not quite, I suspect ;-)
If the conflict occurs between two threads on one app server, then I would expect conflict resolution to happen on the app server and not the storage...
I don't know how you calibrate your expectations, Chris, but conflict resolution is a property of (some) *storages*; the connectoins in application servers have nothing to do with it. For objects served from a ZEO storage, conflict resolution is only possible if: - The underlying storage is conflict resolving (FileStorage is; none of the others which ship with ZODB are). - The storage server can import the class of the object under conflict (this is why the BTrees code ships with ZODB, actually, so that the storage server can use its conflict resolution hooks). Installing the products containing application-defined conflict resolution on the storage server is the only way to enable that conflict resolution in a ZEO-backed deployment. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGudCc+gerLs4ltQ4RAp+kAKCDPFvgzidIJTwnlyqlJfY3qnhqxwCgm9BG +/YxWeQDRNw98dWYP1eJ/zs= =Odf9 -----END PGP SIGNATURE-----
Tres Seaver schrieb:
I don't know how you calibrate your expectations, Chris, but conflict resolution is a property of (some) *storages*; the connectoins in application servers have nothing to do with it. For objects served from a ZEO storage, conflict resolution is only possible if:
- The underlying storage is conflict resolving (FileStorage is; none of the others which ship with ZODB are).
- The storage server can import the class of the object under conflict (this is why the BTrees code ships with ZODB, actually, so that the storage server can use its conflict resolution hooks).
Installing the products containing application-defined conflict resolution on the storage server is the only way to enable that conflict resolution in a ZEO-backed deployment.
As a side-note: this should be mentioned in the README of the QueueCatalog, there is a _p_resolveConflict defined. -- Gruß Joachim
Tres Seaver wrote:
If the conflict occurs between two threads on one app server, then I would expect conflict resolution to happen on the app server and not the storage...
I don't know how you calibrate your expectations, Chris, but conflict resolution is a property of (some) *storages*; the connectoins in application servers have nothing to do with it. For objects served from a ZEO storage, conflict resolution is only possible if:
- The underlying storage is conflict resolving (FileStorage is; none of the others which ship with ZODB are).
Hmmm, I guess I thought ClientStorage was conflict resolving, it sounds like you're saying it's not? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 8/9/07, Chris Withers <chris@simplistix.co.uk> wrote:
Hmmm, I guess I thought ClientStorage was conflict resolving, it sounds like you're saying it's not?
That's what he's saying, yes. ClientStorage is a proxy for the storages in the ZEO server, and it cannot know what features those storages support. It therefore doesn't know anything about conflict resolution. -- Martijn Pieters
Martijn Pieters wrote:
That's what he's saying, yes. ClientStorage is a proxy for the storages in the ZEO server, and it cannot know what features those storages support. It therefore doesn't know anything about conflict resolution.
Indeed, but it's still a storage, there's no reason for it not to do conflict resolution itself. I thought it did ;-) Wouldn't it be beneficial if it *did* do conflict resolution? (afterall, if the conflict can be resolved on the client, why go all the way to the storage server to do the conflict resolution there?) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 8/9/07, Chris Withers <chris@simplistix.co.uk> wrote:
Indeed, but it's still a storage, there's no reason for it not to do conflict resolution itself. I thought it did ;-)
It's not a storage at all. It's a stub for the actual storage which lives in the server. That's a enormous difference. In fact, it would be better if ClientStorage was renamed to ClientStorageProxy or something.
Wouldn't it be beneficial if it *did* do conflict resolution? (afterall, if the conflict can be resolved on the client, why go all the way to the storage server to do the conflict resolution there?)
"Wouldn't it be nice" is a big difference from "I thought it did" :-) It would be nice, but I am not sure it can do it. Conflicts are detected at the storage level, and as that level lives in the ZEO server, that's where resolution has to take place. Propagating the conflict back to the client because it *may* do conflict resolution would be less efficient still, as in most cases there is no conflict resolution available. -- Martijn Pieters
Martijn Pieters wrote:
On 8/9/07, Chris Withers <chris@simplistix.co.uk> wrote:
Indeed, but it's still a storage, there's no reason for it not to do conflict resolution itself. I thought it did ;-)
It's not a storage at all.
Really? I'm pretty sure it implements the relevent storage interfaces otherwise it wouldn't slot in the place of FileStorage...
It's a stub for the actual storage which lives in the server.
That stub *could* do conflict resolution for client-side connects, I thought it did, but it looks like it doesn't.
Wouldn't it be beneficial if it *did* do conflict resolution? (afterall, if the conflict can be resolved on the client, why go all the way to the storage server to do the conflict resolution there?)
"Wouldn't it be nice" is a big difference from "I thought it did" :-)
Yes well, I hoped it was the latter, but it looks like it's the former :-(
It would be nice, but I am not sure it can do it. Conflicts are detected at the storage level, and as that level lives in the ZEO server, that's where resolution has to take place. Propagating the conflict back to the client because it *may* do conflict resolution would be less efficient still, as in most cases there is no conflict resolution available.
I'm only talking about having ClientStorage resolve conflict between the threads of that client, not about propagating conflicts between clients, that *would* be nuts ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 8/10/07, Chris Withers <chris@simplistix.co.uk> wrote:
It's not a storage at all.
Really? I'm pretty sure it implements the relevent storage interfaces otherwise it wouldn't slot in the place of FileStorage...
Just because it implements the interface doesn't make it a storage. It's a stub, a proxy, it passes on
That stub *could* do conflict resolution for client-side connects, I thought it did, but it looks like it doesn't.
How can it? It doesn't have the necessary context.
I'm only talking about having ClientStorage resolve conflict between the threads of that client, not about propagating conflicts between clients, that *would* be nuts ;-)
But it's the only option the ClientStorage has, as it has no clue about conflicts. Only the ZEO server holds enough context for that, AFAICT. -- Martijn Pieters
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Martijn Pieters wrote:
On 8/9/07, Chris Withers <chris@simplistix.co.uk> wrote:
Indeed, but it's still a storage, there's no reason for it not to do conflict resolution itself. I thought it did ;-) It's not a storage at all.
Really? I'm pretty sure it implements the relevent storage interfaces otherwise it wouldn't slot in the place of FileStorage...
It's a stub for the actual storage which lives in the server.
That stub *could* do conflict resolution for client-side connects, I thought it did, but it looks like it doesn't.
It can't *detect* the conflicts, even though theoretically it might be able to resolve them: the detection happens during processing on the server side. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvHSr+gerLs4ltQ4RAnnmAKC5hPR6BoMkitmSPBv6+WCJagJjuACggPqw G7lbAbV/WdictvTpxey9USs= =Mu85 -----END PGP SIGNATURE-----
Chris Withers wrote at 2007-8-10 08:20 +0100:
Martijn Pieters wrote:
On 8/9/07, Chris Withers <chris@simplistix.co.uk> wrote:
Indeed, but it's still a storage, there's no reason for it not to do conflict resolution itself. I thought it did ;-)
It's not a storage at all.
Really? I'm pretty sure it implements the relevent storage interfaces otherwise it wouldn't slot in the place of FileStorage...
It's a stub for the actual storage which lives in the server.
That stub *could* do conflict resolution for client-side connects, I thought it did, but it looks like it doesn't.
Conflict resolution *MUST* necessarily be serialized (otherwise, several conflict resolution processes may conflict with one another). In a ZEO environment, there is only one place which can reliably serialize: ZEO. -- Dieter
Martijn Pieters schrieb:
On 8/7/07, Joachim Schmitz <js@aixtraware.de> wrote:
but _p_resolveConflict is not invoked.
what do I do wrong ?
Is ZEO involved? If so, does your ZEO instance have the Product installed (with all it's dependencies), so the ZEO server can access the resolve method?
Yes ZEO is involved, but where do I specify a Products-directory in etc/zeo.conf ? -- Gruß Joachim
On 8/7/07, Joachim Schmitz <js@aixtraware.de> wrote:
Yes ZEO is involved, but where do I specify a Products-directory in etc/zeo.conf ?
You can't, AFAICT. ZEO servers only support one Products directory in their INSTANCE_HOME, it appears. -- Martijn Pieters
Martijn Pieters wrote:
On 8/7/07, Joachim Schmitz <js@aixtraware.de> wrote:
Yes ZEO is involved, but where do I specify a Products-directory in etc/zeo.conf ?
You can't, AFAICT. ZEO servers only support one Products directory in their INSTANCE_HOME, it appears.
'Products' is just like any other package, so adjusting your PYTHONPATH should be all that's necessary. Moreover, 'Products' is just like any other namespace package (IOW, a package spread over multiple directories using Python's __path__ feature). You can declare namespace packages with Python's own pkgutil or with pkg_resources from setuptools. If we stop pretending Zope lived in its own little world, things are actually quite simple and solutions are quite obvious. -- http://worldcookery.com -- Professional Zope documentation and training
participants (7)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Joachim Schmitz -
Martijn Pieters -
Philipp von Weitershausen -
Tres Seaver