I've attached a screenshoot of the dump in tree view.
Seems NetConnection internally maintained a LinkedList which grows bigger and bigger if the transaction is not committed.
I'll try commit in the loop.

On Fri, Jul 4, 2008 at 11:36 PM, Bryan Pendleton <bpendleton@amberpoint.com> wrote:
I am getting into an OutOfMemory error in my case. Which is similar to the case below. After examining the heap dump, I could find the PreparedStatement is hold too many internal objects and might lead to the MemoryLeak.
I am not for sure whether it is caused by my closing the statement after the long loop, thus causing the client side of derby cashing too many things. Will that be the problem? Thanks.

What are the internal objects which are held? Since you've looked at
your memory dump, can you post the number of instances of the various
classes at the top of the list?

Also, can you re-arrange your application to be able to commit during
the loop? A single transaction cannot be arbitrarily large, as there
are some resources that cannot be freed until the commit occurs.