Ole,
I'm getting pretty tired of this thread, even reading it is annoying.
You're whining about stuff which isn't a problem, and making out like
Zope/ZODB has all these big critical flaws, casting huge assertions
without having enough understanding to make them...
Jan-Ole Esleben wrote:
Jan-Ole Esleben wrote:
1. In the example, just setting _p_changed=1 does _not_ lead to a
conflict error.
I can assure you it will if any other connection to that ZODB does the
same thing on the same object...
executed) it _does_. So there _is_ some implicit magical stuff going
on and ZOPE
Jan-Ole Esleben wrote:
That's my problem. Can you, from the ZOPE documentation, predict that
the example below will cause a ConflictError?
Certainly, try and ask a simple version of these questions on
zodb-dev@zope.org and let Tim or Dieter have some fun ;-)
cheers,
Chris
--
Simplistix
On 12/18/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote:
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.
No,
On 12/18/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote:
I know. This is just example code. Just imagine that both methods
change completely unrelated sets of data in addition to not changing
self.a.
Well, yes, but since both a and also b is non-persistence aware lists,
that means that you in
What you say is all perfectly true except:
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
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
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 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote:
That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true.
You *will* run into these problems in exactly the same cases in any other tool.
But in ZOPE, it is definitely the
case that data and
That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true.
You *will* run into these problems in exactly the same cases in any other
tool.
I'm sorry, but that's just wrong, and I have given examples of such
situations. To simplify, in ZOPE, for any
Am Samstag, den 17.12.2005, 14:56 +0100 schrieb Jan-Ole Esleben:
That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true.
You *will* run into these problems in exactly the same cases in any other
tool.
I'm sorry, but that's just wrong, and
That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true.
You *will* run into these problems in exactly the same cases in any other
tool.
I'm sorry, but that's just wrong, and I have given examples of such
situations. To simplify, in
Am Samstag, den 17.12.2005, 16:43 +0100 schrieb Jan-Ole Esleben:
That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true.
You *will* run into these problems in exactly the same cases in any
other tool.
I'm sorry, but that's just
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote:
To simplify, in ZOPE, for any given product, during a
transaction the product is effectively locked.
This statement is incorrect.
So if I have, say, a
list field that contains some data and a dictionary field that
contains some other
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote:
You should be able to
design stuff incrementally with a little experimentation along the way
without constantly impending danger of it all crashing down on you.
I don't undertand why you say that this isn't possible in Zope.
That's how
Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.
However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting,
I don't understand the problem. How is using XML-RPC incompatible
with persistence? What are you trying to exclude?
- C
On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote:
Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.
I don't understand the problem. How is using XML-RPC incompatible
with persistence? What are you trying to exclude?
I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?
XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC
(on a ZOPE server) and
On Dec 16, 2005, at 8:02 PM, Jan-Ole Esleben wrote:
I don't understand the problem. How is using XML-RPC incompatible
with persistence? What are you trying to exclude?
I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?
You said:
it would most certainly be
I don't understand the problem. How is using XML-RPC incompatible
with persistence? What are you trying to exclude?
I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?
You said:
it would most certainly be extremely hard to foresee the exact
setup of such
The problem setup is this; I explained it above, but it this has
become a long thread:
I write a ZOPE product. I want to make use of other software on the
internet and the services that software provides. So I use the methods
exposed by that software via SOAP, XML-RPC, whatever.
One of those
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
22 matches
Mail list logo
