On 12/19/05, Jan-Ole Esleben <esleben@gmail.com> wrote:
1. In the example, just setting _p_changed=1 does _not_ lead to a conflict error. With the ineffectual code above it (that never gets executed) it _does_. So there _is_ some implicit magical stuff going on and ZOPE tries to take care that only subobjects change (but incompletely)! I strongly doubt it. Zope does not "inspect code". There must be a problem in your testing. Note that if self.a is a standard list, the self.a.append(1) doesn't have any impact on the persistence mechanism or transactions either.
Please, try it out. Delete the if clause and the append in it.
Little bit tricky to try out as testers need to guess what all the missing code is. Also, for this kind of code demonstration, rather than directions for commenting/uncommenting and relying on the tester to restart the server between trails, provide different methods or even different classes. Meanwhile I'm camping over at I-strongly-doubt-it.
3. It is especially confusing that ZOPE behaves differently when using XML-RPC calls. From what you say, it should be the same within the ZOPE system as when using XML-RPC. It gets more complicated with XML-RPC though! The successive XML-RPC call you describe provoke new transactions, surely you're aware of that? Whereas just calling a function of course doesn't.
I'm aware of that. But ZOPE offers XML-RPC and as there is nothing in the documentation about such complex interactions. Also, I was directly responding to what the previous poster had written.
Zope provides for XML-RPC as a server. And it does so with internal transaction support. But there is no extra transactional framework for XML-RPC clients (which your example has). Or for that matter acting as an XML-RPC server nested within some external transaction (which your example has). Either design to avoid this or get your hands dirty with transactions. Some starting points for examples would include any of the relational database adapters. Also in the same space is MaildropHost. michael