I think this is a great question, Michael. Derby clearly differentiates today in its nature as lightweight, embeddable, easy to use and secure, while still being fully functional.

But I think we're going to see more and more "big" users wanting "big" features from it. Do we Just Say No? Is there a way to architect Derby to handle larger deployments while still staying true to its roots?

At a high level one could argue that features like replication and clustering, with the right level of effort and intention, can be made "pluggable", and can be "unplugged" using the module architecture so these features are not available and the classes are not even in the footprint when you want to use Derby as a lightweight database.

If anyone *were* to propose introducing such high-end features, the community would, I would hope, look long and hard at how its built to try to ensure that the impact on the "core" is minimal.

David

P.S. Michael: why do you always say "hey, what do I know?" We should call you Michael Wadduino Segel :)

Michael Segel wrote:
Derby is a very good, lightweight, general purpose, pure java relational
database.
Having said that, I think it's important to choose the right tool for the
right job.

Derby has its historical roots as a lightweight database. It lacks certain
features that are found in Informix or DB2 that would make clustering or
high availability viable. (Data Warehouseing too for that matter.)

To look at using Derby in situations where you would want to implement a
cluster, or some form of high availability, high performance scenario, would
not be a good idea. Its "possible" but not practical.

But your question brings us to a point of asking a critical question... "What is the future direction of Derby?" And this is a loaded question. Do you keep Derby lightweight so that it can
be embedded in to web apps or small lightweight tasks; Or do you add
features that will increase the size and complexity of Derby, but allow it
to compete with proprietary databases like Sybase, Oracle, Informix, DB2,
etc ...

This is a design issue that needs to be addressed by Sun, IBM, Apache and,
of course the user community at large.

I think that for Derby to survive in the long run, it needs to determine its
niche and then strive to be the best in that niche.


But hey! What do I know?
I'm just some developer who has his own opinions and vision of the future.
;-)

-----Original Message-----
From: Jean T. Anderson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 6:33 PM
To: Derby Discussion
Subject: Re: Can derby instances be clustered ?

Legolas Woodland wrote:
Hi
Thank you for reading my post.
can derby instances be clustered together ?
can some one lead me to some resources or steps to cluster two instance
of  derby which i run on my own computer ?
Sequoia supports clustering; see http://sequoia.continuent.org/HomePage .

Also, Emmanuel Cecchet did a presentation at ApacheCon US 2005 and it is
available at
http://www.continuent.org/uploads/sequoia/Resources/2005-12-
14SequoiaApacheCon05US.pdf

regards,

 -jean



Reply via email to