[Zope-dev] DB.close() needs to be called

[Chris McDonough]

Maybe normal shutdown should manually call the shutdown signal handler
function and normal restart should manually call the restart signal
handler function?  

On Wed, 2002-11-13 at 10:28, Toby Dickenson wrote:
> On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote:
> > >>>>> "TD" == Toby Dickenson <tdickenson@geminidataloggers.com> writes:
> >     >> This is a bad thing for the Berkeley storages because their
> >     >> .close() must get called or you'll end up with corrupt
> >     >> databases or worse <wink>.
> >
> >     TD> How much of that paragraph is covered by the wink?
> >
> > The "or worse" part.  If you've enable autopacking and you don't
> > cleanly close the storage, you won't exit the process because the
> > autopack thread won't get stopped and joined.
> 
> Yes, I had the same problem with DirectoryStorage, which uses a seperate 
> thread to move writes from its journal directory into the database directory. 
> 
> >  We could make the
> > autopack thread a daemon process
> 
> Thats how DirectoryStorage now works.
> 
> > It wouldn't be good, but remember that we run BerkeleyDB in
> > auto-recovery mode, so it means that the next time you open the
> > database, it will run recovery (you can also run recovery manually).
> > However, depending on your checkpointing policy, and the size of
> > committed data since your last checkpoint, recovery could end up
> > taking a long time.
> 
> Last time I looked at your BerkeleyDB storages, the administrator needed to 
> implement his own checkpointing policy. I always thought that was a 
> disadvantage. Would it now be a good idea for the storages to trigger their 
> own checkpointing inside the autopacker thread?
> 
> > Sure, any number of bad things can happen at any time, and defense
> > against that is one of the benefits of using BerkeleyDB underneath.
> > But under normal operations, we definitely want to exit cleanly.
> 
> Agreed, on both points.
> 
> 
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )