Thanks for the clarification, Kevin.  That was roughly how I understood it, but glad to have confirmation.

I'm definitely seeing doubling of the file size when I trunc and reload, but I'm going to dig around and make sure I'm not inadvertently holding on to things.

If I can narrow things into a simple testcase, then I'll definitely pass it along.

- Chas

On Nov 3, 2009, at 12:09 PM, Kevin Day wrote:

There's no vacuum ability.  The allocator works as follows:
 
As records are freed, the space allocated to that record becomes available for another record of the same or smaller size.  If the record has smaller size, then the remaining space is pretty much wasted (although I think there may be something that splits the remaining space and adds it back to the free pool - I can't remember).
 
If you are truly deleting all records in the database, then the size of the file should definitely not double, unless all of the new data is bigger than all of the old.
 
 
Unit test TestRecordManager.java # testDeleteAndReuse does pretty much what you are describing (although at a smaller scale).  I do know that there was a bug awhile back (fixed in SVN head for sure) that caused a bit of a leak when a BTree was deleted (the very head of the tree wasn't reclaimed) - but that was over a year ago.
 
If you want, reply back with a unit test that shows the behavior you are seeing, and I'll take a quick look.
 
- K
 
----------------------- Original Message -----------------------
  
From: Chas Emerick <cemerick@snowtide.com>
To: JDBM General listserv <jdbm-general@lists.sourceforge.net>
Cc: 
Date: Mon, 2 Nov 2009 13:10:30 -0500
Subject: [Jdbm-general] Deletes, freeing blocks, vacuum, et al.
  
Just trying to lay some breadcrumbs for others, since I don't see any  
definitive statements about this in the archives...

Is there any mechanism for compacting jdbm files?  Briefly looking at  
the implementation leads me to think that deleting records (and,  
presumably by extension, removing mappings from HTree, etc) just adds  
blocks to a free list, where they would be picked up by future puts,  
etc.

However, that doesn't *seem* to be the case: I've got a process that  
pushes a ton of data into a jdbm file; deleting all of it later on and  
then repeating the load with identical data doubles the file's size.

Is there a configuration option I'm missing, am I likely doing  
something wrong in general, or have I misunderstood the nature of  
jdbm's storage re-use policy?

If the latter, is there a vacuum process (or similar) floating around  
so I can shri nk a file when desired?

Thanks,

- Chas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jdbm-general mailing list
Jdbm-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-general