My application has a feature that requires resetting the contents of
several of its DB_QUEUE databases. I thought a reasonable way to do
this was to 1) close each queue with a DB_NO_SYNC flag and 2) reopen
with DB_TRUNCATE. The reason I wanted to close with DB_NO_SYNC is
avoid the time it takes to sync the database to file with data that is
no longer needed. After a reset done in the fashion the database
becomes unreliable sometimes losing records that were inserted. I've
narrowed this down to a simple test case and it is reproducible. If I
don't use shared cache or if I don't use DB_NO_SYNC the database works
reliably but the combination of these two leads to runtime trouble. I
suspect the shared cache gets confused in some way that causes it to
stays confused even AFTER the database file is reopened again from
scratch!

Does anyone have a better way of quickly resetting a berkeley DB_QUEUE
database? I can't readily wipe the whole environment because only a
subset of the db files in the env need to get reset and yet they all
share the env cache. In fact I really don't want to muck with the
cache because there is another db using the same cache that has gobs
of data in the cache that I don't want to have to reload. I'm stuck!

NEVER MIND! There is actually a db.truncate() API that does the trick
and much faster.

Cheers,
David

On Jan 24, 6:43 pm, DavidYoakley <david.yoak... (AT) gmail (DOT) com> wrote:

NEVER MIND! There is actually a db.truncate() API that does the trick
and much faster.

Cheers,
David

On Jan 24, 6:43 pm, DavidYoakley <david.yoak... (AT) gmail (DOT) com> wrote:

NEVER MIND! There is actually a db.truncate() API that does the trick
and much faster.

Cheers,
David

On Jan 24, 6:43 pm, DavidYoakley <david.yoak... (AT) gmail (DOT) com> wrote: