db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: Best Practice: Embedded Derby Location?
Date Tue, 19 Sep 2006 18:04:56 GMT
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.

View raw message