[Zope] Re: [ZC] 1314/ 2 Reject "ZODB size explosion"

[Casey Duncan]

The best forums to get answers to your questions the Zope and Plone
mailing lists (I am cc'ing the main zope list in case anyone else has
ideas). The collector is not a discussion forum or a place to discuss
application code.

"Write-on-read" means that objects are changed when they are viewed. If
this happens on nearly every request, then the size of the database will
balloon. Since writing to an object is very easy in Zope and can happen
in a myriad of ways, you will need to do a bit of debugging to determine
where in your application (or a third party add-on) this is happening.
This is not debugging Zope, it is debugging your app.

-Casey

On Wed, 5 May 2004 23:07:32 +0300
Turkia M <turkia at james.hut.fi> wrote:

> 
> hello,
> you are probably right. what I was hoping for was any advice on how to
> fix the database to a consistent state. we are losing 3 months of work
> here. i was not expecting to have to debug zope and plone to finish
> this project and i may not have enough experience to do that, at least
> not with this timetable.
> 
> anyway, i tried to create a new plone instance, copy-paste the data to
> the new instance and remove the mentioned
> products and the old instance.
> at first the db size returned to normal. however none of the users in
> plone object's acl_users could log in anymore. and after running a
> script that was intended to fix owner attributes of objects in member
> directories the db exploded again and it didn't fix the login problem.
> i'll include the script if it helps any. btw. using recursive=1
> somehow froze the whole system.
> i didn't really understand what the "writes occur for read requests"
> means. i recall CMFBibliography gave some error on read-only
> attributes but i don't have that information anymore.
> thanks,
> mika
> 
> from Products.PythonScripts.standard import html_quote
> request = container.REQUEST
> RESPONSE =  request.RESPONSE
> 
> import string
> Members = context.Members
> r=[]
> for i in Members.objectIds():
>     try:
>        u = container.portal_membership.getMemberById(i);
>        m = getattr (Members, i)
>     except:
>        pass
>     else:
>        if u is not None:
>           context.plone_utils.changeOwnershipOf(m, i, recursive=0)
>           r.append(i + " changed")
>        else:
>           r.append(i + " not changed")
> return string.join (r,'\n')
> 
> 
> 
> 
> On Wed, 5 May 2004, Collector: Zope Bugs, Features, and Patches ...
> wrote:
> > Issue #1314 Update (Reject) "ZODB size explosion"
> >  Status Rejected, Database/bug critical
> > To followup, visit:
> >   http://zope.org/Collectors/Zope/1314
> >
> > ==============================================================
> > = Reject - Entry #2 by Caseman on May 5, 2004 9:58 am
> >
> >  Status: Pending => Rejected
> >
> > It is highly unlikely that this is a Zope bug. Given your
> > description it is almost certainly due to one of the products you
> > mentioned or your application's use of them. These types of problems
> > are common in applications where database writes occur for read
> > requests (which is generally a bad idea).
> >
> > Suggestion: Perform various read requests in your application, and
> > check your undo log. If it contains entries for these requests, look
> > to see where the database write is occuring.
> >
> > I am rejecting this bug because I do not see evidence that the cause
> > is Zope itself and not application or other third party code. If you
> > can find further evidence to the contrary, feel free to reopen this
> > issue.________________________________________ = Request - Entry #1
> > by mtz on May 5, 2004 2:19 am
> >
> >
> > Uploaded:  "analyze_py_output"
> >  - http://zope.org/Collectors/Zope/1314/analyze_py_output/view
> > A strange problem where database size was originally about 6MB but
> > after installing I18NLayer (first release 0.5.5, then CVS) and
> > CMFBibliography (CVS HEAD) the db suddenly grew up to 300 MB.
> > Packing returned it to about 35MB, but growth rate was not fixed,
> > and trivial changes double or triple the size. Problem seems to be
> > related to OOBTree.OOBucket and_IOBTree.IOBucket taking most of the
> > space (see below).
> >
> > ==============================================================
> >
> >