db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gregsmit <gregs...@us.ibm.com>
Subject Memory Leak or Expected Behavior - BtreePostCommit
Date Mon, 29 Oct 2007 14:40:18 GMT


Hi,

We have an application that is using embedded Derby (10.3), where we do a
lot of adds and deletes.

When we run this application under our stress scenarios, we see a memory
leak in Derby.  When we look at our heap dumps, what we see is an ever
growing number of these classes:

org.apache.derby.impl.services.deamon.ServiceRecord
org.apache.derby.impl.store.access.btree.BtreePostCommit

I found some other documentation that said that the BtreePostCommit is a job
that runs after a delete is committed, that frees space in a Btree, and that
it requires a table lock.  What I think is happening is that because we are
running at a constant heavily stressed state, is that our deletes are
occurring, then this job is being placed on a queue after the commit.  But
because we are in a heavily stressed state, these jobs never run, so the
queue grows larger and larger.

Does this theory sound right, or does anyone have a better explanation?

OK, assuming its right -- Is this the correct behavior?  Should theses Post
Commit jobs continue to get queued, and never run?  Is there a way we can
force them to take grab the locks and complete?  Maybe something wrong with
the way that we are committing, that doesn't allow them to run?

We do not have a lot of experience with Derby, so we may be doing something
wrong.

Thanks for any help,
Greg


-- 
View this message in context: http://www.nabble.com/Memory-Leak-or-Expected-Behavior---BtreePostCommit-tf4712054.html#a13468710
Sent from the Apache Derby Users mailing list archive at Nabble.com.


Mime
View raw message