db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: Derby v SQLite
Date Wed, 31 Oct 2007 01:01:33 GMT

Gears is a client side framework for web applications. If you have a Java
application (be it client standalone, web or server) and you want to embed a
database system and be able to port it across platforms, Derby makes a lot
of sense (being 100% Java); It has a strong and active development community
and it is integrated in lots of other products (
http://wiki.apache.org/db-derby/UsesOfDerby). One can also purchase support
outside of the community with Java DB (http://developers.sun.com/javadb),
which is Sun's supported version of Apache Derby and which comes bundled in
Sun JDK 6 as well as GlassFish Java application server.

Last, Derby has been developed with multi-user support and has been around
for around 10 years, in various incarnations. If multi-user support is
another important point for your application, Derby has a multi-threaded
core engine with row-level locking and support for standard isolation
levels, as well as online back-up / restore capabilities, data/network
encryption and you can enable an embedded instance of Derby to be remotely
accessible, if required.

Hope this helps,


On 10/30/07, derby@segel.com <derby@segel.com> wrote:
> There are a couple of issues raised by your post/email...
> First the architecture decision on whether to use a java db or to use a c
> language based db.  You don't really talk about your application and any
> design constraints. In some respects, the database could be separate from
> your app. (A centralized DB server for example.)
> The second issue is Derby vs whatever....
> What you're concerned with is finding a tool that has gained enough
> critical
> mass to be viable long term. I asked a question on linkedIn regarded what
> criteria is there in determining if a software language/architecture has
> obtained "critical mass". (COBOL, C/C++, Java, Python, ... all have or had
> reached critical mass are viable long term)
> If we looked at MySQL, it has but it hasn't. Sure its free to develop in,
> but wait until your app goes in to production.... I think that MySQL has
> hit
> a ceiling and I don't expect to see very much more growth.
> If you look at Derby, it exists as Cloudscape, Derby, and JavaDB.
> (Although
> IBM is pulling its support....)  As JavaDB, I believe that Derby is close
> to
> achieving "critical mass".
> With respect to SQLite, I don't think that it has achieved "critical mass"
> nor will it. There are a lot of other products out there that just doesn't
> have the mind share to survive.
> Its nice that Google "supports" it, but is Google like Microsoft going to
> support and promote its own development platform like .net and C#?
> Does this make sense?
> As an "early" adopter, you're taking a risk that your platform/technology
> will be viable over the next 5+ years or is portable enough to be easily
> migrated....
> -G
> > -----Original Message-----
> > From: David Leader [mailto:d.leader@bio.gla.ac.uk]
> > Sent: Tuesday, October 30, 2007 2:54 PM
> > To: Derby Discussion
> > Subject: Derby v SQLite
> >
> > In another thread I recently wrote "I'm happy with the way that Derby
> > has behaved, but I'd like to ask a provocative question nevertheless..."
> >
> > Back in the summer, when I told my son (who is a computer
> > professional) that I had a Masters student porting my MySQL db to
> > Derby, he told me I should be using SQLite, which is what Google is
> > using in its Gears thing. I persisted with Derby, mainly because it
> > is Java and my app was in Java, but I'd be interested to know what
> > people regard as the relative strengths of weaknesses of the two
> > embedded DBs.
> >
> > David
> >

View raw message