Daniel Jue wrote:
Hi,
I would like to use Derby to store some web application meta-info, and
I think I'd like to have it embedded (only my web app's POJOs will
access it). It's gonna store simple text like menu urls and global
user preferences, which I was previously storing in XML files deployed
with my project. The db will also have tables for saving user
settings. From what I understand, there is a way to use the embedded
database so that port 1527 is not opened, which is what I want.
I am using Eclipse, Tapestry and Tomcat 5.5. Should the Derby db
folder structure reside somewhere in my application's web context
(i.e. packaged in my .WAR)? Or should it be somewhere outside the
application, like C:\MyDerbyDBFolder ?
I guess with the database outside the web app, I can re-deploy without
overwriting the database. Is this what you thin web app developers
are doing?
BTW, right now I have the Derby.jar included in my project's lib
folder, not in Tomcat's shared lib dir.
Dan
Hi Dan -
Derby is designed to be a shared resource for all threads in the JVM in
which it is started so the Best Practice is to setup Derby in that
manner. I've seen many problems occur when Derby is loaded in a
restricted classloader. These problems typically result in certain
operations failing with NullPointerExecption or ClassDefNotFound
exception. Then there is the problem of another application (call it
APP2) also loading the Derby driver in it's runtime space and opening a
database that your application (call it APP1) has opened. You now have
two DBMS systems running and neither the APP1 nor APP2 DBMS is aware of
the other, each has it's own buffer cache, transaction management
system, locking, etc. and when transactions from both processes happen
at the same the time the DB will become corrupted beyond repair.
My recommendation is 'Do not do it'. Derby is a full-fledged database
management system, there is no additional cost that I am aware of to
loading it as such and when another application or three needs to
utilize it you begin to gain from the economies of scale from sharing
buffer caches, etc.
