On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote:
> >>>>> "TD" == Toby Dickenson <[EMAIL PROTECTED]> 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  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to