Gads, I'm out of it today. Thanks, *Bryan*, not Mike...
I am doing some of that, and am looking into doing more of that.
But it's more than possible that I'll have a lot of open, *active* databases.
We're talking a lot of data, potentially 10s of GB of BLOBs. I was concerned a single Derby DB would not be able to handle this well, so I asplit this up into multiple databases. This also gives me future flexibility to spread the databases across different disks to avoid contention.
But if you think this can be managed fine in a single database, well, I could be convinced to go that way... :)
DavidOn Tue, Jul 20, 2010 at 7:37 PM, Bryan Pendleton <email@example.com> wrote:
If you can manage the performance hit, I think the best way to keepHi. Could you point me to a page, or just tell me, what
configuration settings I can tweak to reduce the overall memory
footprint of a booted Derby database. Losing performance is pretty much
OK, this is not a time-critical part of our code, but I have a lot of
databases open and it's impacting memory footprint pretty significantly.
a lid on the overall resource usage is to change your approach, and *not*
keep a lot of databases open, but rather close each database when it's
not in use, and then re-open it upon demand.