That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! In Zope, it's just the whole object that's tainted. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. This had never occured to me as a _real_ problem before. Of course, if you just create self contained code on a small scale that doesn't talk to other programs on the web, you'll likely not run into any great problems because of this.
Ole 2005/12/17, Lennart Regebro <[EMAIL PROTECTED]>: > On 12/17/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > > It's not about the threads or processes being tied up and waiting, > > it's about the transaction breaking: because the internal call (the > > one from the second server back to the first) changes the object on > > the first server, and thus when the first server checks wether the > > object has changed after the transaction should close (during the last > > return), it finds that indeed it has, and before it could write to it, > > so it raises a conflict error invariably. > > This is still not a problem that has anything to do with Zope or > persistenace, but it is quite simply just a conflict error. It will > happen anywhere you do things like this. > > It will also only happen when you, in the processor of modifying an > object, calls a method on another server, which, before that call > finishes, makes a call back and modifies the *same* object. > > I can't currently dream up any scenario where this happens, but I'm > happy that Zope raises an error when it does. A system that does NOT > raise an error in this situation is broken. If you get problems like > this, you need to make changes to the software so that this does not > happen. The right way to do that depends on your application. > > -- > Lennart Regebro, Nuxeo http://www.nuxeo.com/ > CPS Content Management http://www.cps-project.org/ > _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )