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] 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 )
