To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. This statement is incorrect.
You're right. It should be "during any transaction where there are potential changes to the object". And I agree, it's actually a lot more complicated than I'd thouht at first. What I describe can happen, but it happens under rather magical circumstances. I have an example where it actually happens; this is code from a product that is instantiated twice, one of those instances called TPCDest, the other TestPChanged; the method called directly is "TestPChanged.test()": security.declareProtected("Use TestPChanged", "test_internal") def test_internal(self, args=None, args2=None): "Called by test via XML-RPC" if args2: self.a.append(1) self._p_changed = 1 if not args: import xmlrpclib s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/", allow_none=True) s.TestPChanged.test_internal(1) return self.a security.declareProtected("Use TestPChanged", "test") def test(self, args2=None): "Called directly via ZOPE" if args2: self.a.append(1) self._p_changed = 1 import xmlrpclib s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/", allow_none=True) return s.TPCDest.test_internal() Zope obviously looks at the code, because if you remove the "if args2" (which is _never_ true), then a ConflictError happens. Maybe I'm stupid, but could someone point out _where_ exactly I am?
No. It does happen, and it _did_ happen in my original problem. Zope doesn't even care if anything actually changes, it just considers an object changed that set self._p_changed=1. No, se above.
You're right that it doesn't always, but see my example.
Yes. You said "different sets of data". That reasonably means different objects. If it doesn't, yuo need to take a long hard look at your object hierarchy.
Simply not true. What if I have a field titles (that is a hash of titles to Book objects) and a field comments (that is an array of comments on the library)? Is that so obviously not a sane example?
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. Eh, no they aren't. Please don't just claim stuff. You do.
I don't. I at least try to give reasons wherever I make a statement that could be challenged.
In ordinary systems, you would have to find a way to store the data and retrieve it, thus having a model that isn't implicit and entangled with your code. What is implicit with it?
See the example for some major implicitness. It's also implicit because you have no control over what a transaction considers a tainted object. (You have no real control over the transaction).
If you have two different processes changing the same set of data, you will get confllict errors. You claim that you will not, but this is false.
I am explicitly talking about changing different sets of data within the same object. You noted that above yourself.
You claim that you can't control what a persistent class store. That is false.
I don't. I say that if I want to avoid such problems as I describe altogether, I cannot store anything in a persistent class and thus lose most of what makes ZOPE so interesting.
You claim that the whole Zope product gets locked, that is false. It's on a object-basis, not a product basis.
I never said that, or at least I didn't mean it. If it sounded like that, I apologize (maybe I used Product metonymically for instance somewhere, which would not be a good idea, I agree).
You claim that things get locked that shouldn't be locked in Zope. It is not clear to me why you say that.
See the example. Ole