[ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

[Chris McDonough]

On Fri, 2004-03-05 at 05:53, Toby Dickenson wrote:
> On Friday 05 March 2004 00:56, Chris McDonough wrote:
> > On Thu, 2004-03-04 at 17:18, Casey Duncan wrote:
> 
> > > > What I'm unsure about is whether pack would keep recent revisions to
> > > > unreferenced objects,
> > > 
> > > It won't.  A pack will now destroy anything unreferenced.
> 
> Thats true for the reference-counted BDB storages. (And in theory its 
> dangerous.... There are some corner cases where these unreferenced objects 
> can get written by normal ZODB usage). 

Yikes.  I dimly remember this.  Do you happen to remember one of those
concrete corner cases to jog my memory?

> Unless I missed a recent change, 
> FileStorage will keep all the objects modified within the pack window. But 
> not their sub-objects.

You likely didn't miss a recent change.  I'm probably wrong; I was
looking at MappingStorage and DemoStorage pack algorithms when I made
that assertion (reading FileStorage's is still a bit like reading
Aramaic, although Jermey has done a nice job of partitioning it),

> > > I was thinking it could be an option in a normal pack to not remove
> > > objects that were modified within the pack window even if they aren't
> > > reachable. What I hadn't considered though are persistent subobjects.
> > > Dealing with those would make it more complex in the general pack.
> >
> > Right.  It's not really a pack operation, although like a pack it may
> > need to operate on all the objects in the database.
> 
> Thats how DirectoryStorage's pack works as standard.

Right then.  In that case, I think we just need to prevent the deletion
of objects referenced (directly and indirectly) from a particular type
on a pack.  In particular, we need to prevent the deletion of "current"
session data object subbobjects (and any of their subobjects,
recursively).  This still isn't quite a pack, but getting closer. ;-)

- C