db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Newsham" <jnews...@referentia.com>
Subject RE: embedded derby -- does it leak
Date Wed, 15 Feb 2006 19:20:12 GMT


Thank you for your reply.  With all due respect, I don't feel that users of
a database should "assume that there will be memory leaks".

I appreciate that Derby is an open source project, nevertheless it is a
database product, and databases are expected to be robust, whether
commercial or open source.  Database systems manage critical data and run
for long periods of time, so it's not tolerable for a database to crash
after exhausting available memory due to a persistent leak.  Furthermore,
Derby sells itself on being robust and having a small footprint.  

If the commercial version (Cloudscape) is the same codebase with some extra
hand-holding, I don't feel we need that for our project.

In response to Rajesh who asked the circumstances of the OOME my colleague
experienced, I don't have that information yet.  I intend to ask for more
details, but I'm not sure if he still has the code.  I was a little
skeptical when I heard that he had OOME problems, and wanted to poke around
in JIRA a little and get feedback from the community before probing further.

Thank you all for your input.  All further comments are welcome.


Jim Newsham

-----Original Message-----
From: Michael Segel [mailto:derby@segel.com] 
Sent: Wednesday, February 15, 2006 6:01 AM
To: Derby Discussion
Subject: Re: embedded derby -- does it leak

On Tuesday 14 February 2006 9:21 pm, Jim Newsham wrote:


Assume that there will be memory leaks.

No code is perfect, and there may be memory leaks not just in Derby, but the

JVM implementation that you are using, or the JDBC drivers.

This isn't limited to Derby. Other Open Source as well as commercial
are going to be prone to leakage.

> Hi,
> We need to include a database along with our Java-based desktop
> application, and for deployment/maintenance reasons, an embedded database
> would be ideal. I'm evaluating whether derby will suit our needs, and so
> far I really like what I see.  However, some colleagues have told me that
> they had evaluated derby in the past (a few months ago), and that they
> passed on it after seeing memory leak problems which resulted in
> OutOfMemoryException.  The application may need to run for a long time,
> may generate a very large amount of data, therefore, a recurring memory
> leak is a showstopper.  I wanted to give Derby another look before moving
> on.
> I looked through JIRA to try to identify bugs related to memory leaks.  I
> found:
> DERBY-756 (fixed; reported against, but doesn't say which version
> the fix is applied to)
> DERBY-912
> I skipped over these because they appear to be client/server (please
> correct me if I'm wrong):
> DERBY-210
> DERBY-557
> I also browsed the derby-user list, but didn't find anything substantive.
> So, on to my questions:
> How stable, robust, and well-tested is derby?  How often do critical bugs
> find their way into production releases (please include "memory leaks" in
> the definition of critical)?  How long does it take for bugs such as the
> above to make their way into a production release, and when could I
> reasonably expect these two to be available for production?  Are there
> other outstanding memory/leak related bugs which I'm not aware of?  Would
> you recommend Derby for my project?
> Thanks,
> Jim Newsham

Michael Segel
Michael Segel Consulting Corp.
(312) 952-8175 [mobile]

View raw message