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 <[EMAIL PROTECTED]> 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.
