db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Segel" <mse...@segel.com>
Subject RE: embedded derby -- does it leak
Date Wed, 15 Feb 2006 20:01:10 GMT
Jim,

I think you misunderstand what I am saying.

As a good software developer, you should have a bit of a "defensive"
attitude when you design a solution. By this I mean, you should plan for the
worst, while hoping for the best. (Which is what you're doing by reviewing
the open bug list...)

Most commercial shops and internal development organizations do not always
take the time to perform not "best practices" but "accepted practices" of
software development. When was the last time you participated in a formal
peer code review? Even with white box and black box component testing,
memory leaks can occur.

Because of this, memory leaks are far too common and some never get
detected. 

To give you a real life example, I was on a customer site implementing a
Java API for an Oracle 8i instance. Reading the release notes, I was limited
to using one specific JDBC driver. (The others had bugs that were not fixed
and would impact my app...) I found a nasty memory leak in the driver. Took
me 3 days to convince the right group at Oracle that it was a bug and told
them that it would take no more than 24 hours to find/fix/test and release a
new version/patch. The point being, this JDBC driver had been out for
several months without anyone finding the bug. (Ok, so I was inserting large
XML Blobs at a pace of 1 every 2 seconds... Something not everyone did.)


The point being that memory leaks do occur regardless of the product or its
pedigree.  My comment was to say that you should expect *all* databases to
have memory leaks. If not in the database, but the JDBC drive or App Server
or some additional component. 

The key is to identify the reported bugs and consider the following metrics:

1) The severity of the bug. (Factor in the frequency and conditions that
caused the bug to pop up)

2) Time from Bug reporting to when it was confirmed/reproduced and what was
the suggested fix/work around.

3) Time to patch release or next "dot" version release.

These should be more critical in your decision making than just having a
memory leak reported.

What happens if you chose a different product, got in to production and
found out that you had a major critical bug and that there wasn't enough
community support to get the issue resolved? Or that in resolving the one
bug, another series of bugs were created/revealed?

Does that make more sense?


I do think you're taking the right approach to review a product prior to
implementation.  If you are going to look at an open source product, you
should also consider the community support.

-Mike

> -----Original Message-----
> From: Jim Newsham [mailto:jnewsham@referentia.com]
> Sent: Wednesday, February 15, 2006 1:20 PM
> To: 'Derby Discussion'
> Subject: RE: embedded derby -- does it leak
> 
> 
> 
> Michael,
> 
> 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.
> 
> Regards,
> 
> 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:
> 
> Jim,
> 
> 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
> programs
> 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,
> and
> > 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 10.1.2.1, 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
> Principal
> Michael Segel Consulting Corp.
> derby@segel.com
> (312) 952-8175 [mobile]
> 
> 




Mime
View raw message