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

Toby Dickenson tdickenson@geminidataloggers.com
Wed, 13 Nov 2002 15:28:18 +0000


On Wednesday 13 November 2002 2:10 pm, Barry A. Warsaw wrote:
> >>>>> "TD" =3D=3D Toby Dickenson <tdickenson@geminidataloggers.com> wri=
tes:
>     >> 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=20
thread to move writes from its journal directory into the database direct=
ory.=20

>  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=20
implement his own checkpointing policy. I always thought that was a=20
disadvantage. Would it now be a good idea for the storages to trigger the=
ir=20
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.