db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Jue" <teamp...@gmail.com>
Subject Re: Best Practice: Embedded Derby Location?
Date Tue, 19 Sep 2006 18:29:51 GMT
Stanley,

Thanks!  I only have one application that is going to use it for the
foreseeable future, and that's a web app served by Tomcat.
So if I read your suggestion correctly, I will put the Derby.jar in
the Tomcat shared lib directory.  And I'll have the actual database
directory structure live outside of Tomcat, i.e. C:\MyDerbyDB\

Dan

On 9/19/06, Stanley Bradbury <Stan.Bradbury@gmail.com> wrote:
> 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.
>
>
>
>

Mime
View raw message