Thanks for the reply.
This is what I understand based on your reply and from the paper by Jim.
1. That there are solutions currently being worked on by DC (implied).
Yes, worked on does not mean 'Coming Soon to a Zope near You!' :)
2. That if an app, either by it's nature or thru it's developers design,
eliminates or handles conflicts before commits are made to the ZODB,
that high write situations are not a problem.
Slap me upside the head if I misunderstand. :)
If this is the case then I think this is great news. Okay, it may not be
news. And I may be the only clueless soul in ZopeLand. :)
Is number 1. below something that would take place with BTree Folders?
Or is this apples and oranges?
Once again, thanks.
Evan Simpson wrote:
> ----- Original Message -----
> From: Jimmie Houchin <[EMAIL PROTECTED]>
> > Will an app as described above still suffer from problems with high
> Possibly, but only if there are hidden hotspots. For example, in your
> message-appending scenario, are these messages being added to the same
> Folder? If so, the Folder is getting written with each object added to it,
> and will be a source of conflict. If the objects that your users are
> editing are cataloged, the Catalog is a hotspot.
> There are two independent attacks on this problem underway:
> 1. Make Folders and Catalogs store meta-data about their contents in a data
> structure consisting of small persistent objects, like B-Tree nodes. This
> reduces the scope of potential conflict (and the size of the update required
> by a write) to the size of one of these nodes.
> 2. Implement the application-level conflict handling you read about, so that
> Folders and Catalogs can decide that two writes don't conflict after all,
> and merge them into a single update.
> Evan @ digicool & 4-am
> Zope maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -