Bryan Pendleton <[EMAIL PROTECTED]> writes: > > > database. As the data are published scientific data I can share my > > source code > > and the data. Everything is available on > > > > www.fysik.dtu.dk/~munter/derby/ > > Thanks for sharing your sample program. It looks like you are creating > statements, but never closing them. > > Each call to cDerby.createStatement() should be matched with a call to > close() on the statement. > > thanks, > > bryan > >
The program is the same as I was using both when running an embedded server and in network server mode. Of course the commit after 50 rows and the reconnect parts are things I first added when the original version of the program failed to add all records. But exactly this program makes the Network server run out of memory after 6956 and 23154 rows, respectively (as described in an earlier post). But thanks for pointing out the missing call to close(). I think you spotted the memory-leak there. And it explains why running "derbyrun.jar server runtimeinfo" showed so many Statements in the cache. Of course this would have went undetected if I only inserted a few thousand rows. I have done some runs today where I remember to call close() and don't reconnect all the time and it seems to run without problems. I would think that still active statements would be closed implicit when closing the Connection, but that seems not to be the case (in Network Server mode). For me this "minor" bug in my own code is not so bad as the uploaded program is only used once (by myself) to insert all data in the database. But that Derby can run out of memory if somebody forgets to close created statements is potentially a more serious bug. Of course it requires an attacker to first be able to create a connection to the database server, and in that case he can do more interesting things than just making the server crash. Thanks for the replies - Ture Munter
