[Zope] Zope leaking memory?

Chris McDonough chrism at plope.com
Mon Sep 13 16:52:32 EDT 2004


On Mon, 2004-09-13 at 16:28, Alec Mitchell wrote:
> On Sunday 12 September 2004 10:25 am, Chris McDonough wrote:
> > Note that explicit transaction control is quite dangerous in Zope if
> > used in the normal course of operations invoked by TTW users (for
> > reasons too obscure to go into here: see recent posts to ZODB-dev).
> > Using it in a script is typically fine though.
> 
> Is this the case even for subtransaction commits?  

Yes, subtransaction commits are actually even more dangerous in current
Zopes than regular transaction commits due to an obscure bug in ZODB in
all versions prior to 2.7.3.

But they're really only dangerous if you (or someone using your code)
inappropriately catches an exception during one of the commits. 
Inappropriately catching exceptions raised by a transaction commit is a
pretty good way to get inconsistent app state in your database.  See the
ZODB-dev thread for more info.

FWIW, this probably won't be solved entirely in any version of Zope 2.7,
and maybe not even 2.8 (but hopefully).

> I have a particular piece 
> of code that adds a new piece of content to a CMF Site programmatically as 
> the result of a TTW action.  During the course of adding the content setId() 
> is called on the object, which fails consistently unless a subtransaction is 
> committed prior to the call (I believe the issue was that the created object 
> wasn't yet stored in the ZODB, so calling setId (which causes a copy) 
> failed).

Can you call setId on it after its attached to another persistent object
instead of trying to call setId on it while it's "bare"?  But..
actually, why does setId cause a copy?  setId seems pretty innocuous at
least in name ;-)

>   Is this a risky practice?  If so, what's the alternative?  Thanks.

Yes.  See above.

- C




More information about the Zope mailing list