Hi, If your 2 applications are running in the same Java Class Loader, then you can just access the database with one Derby embedded instance. On the other hand, if your applications are running in different Java class loaders, you should start start Derby in Embedded Server mode and then have the 2 applications accessing the database with the Derby JDBC Network Client driver. Note that you can also start a Derby instance in embedded mode with the first application's class loader and then enable remote access (by turning on Server mode[ http://db.apache.org/derby/docs/10.4/adminguide/tadminconfig814963.html]) within that embedded instance to enable the second application to connect with the client driver.
Running Derby as a server in a separate process and different host machine is usually better if the load is already going to be heavy on the application server (middle-tier) - Trade-off is the network layer (overhead due to data marshalling and unmarshalling & network latency) between the application server and the Derby server if running standalone. Derby always runs embedded, the server layer is really the client-server layer that allows a remote client to connect to a Derby instance. The server layer can itself run embedded in some application or as a standalone process... So I'd say given your context that it is really a question of trade-off as far if you can afford to have the database engine running embedded in your application server, removing the network layer _but_ running in the same JVM as the app server. As I mentioned above, _if_ your applications are running in separate (dedicated) Java class loaders, then you will need to have Derby's Server mode enabled so that the second application accesses it via the JDBC network client driver in TCP loopback mode. You can't have 2 Derby engine instances going after the same database (no DB shared-disk cluster support). Also, only having 1 Derby instance to handle mutliple databases only require 1 database cache for all DBs. Sorry if I sound like repeating myself but if you can have Derby run embedded inside TomCat, then you can have your 2 applications using the embedded driver to access Derby for both databases (1 DB cache) _or_ if they are running in separate class loaders, you could have Derby running in embedded server mode and have the second application use Derby network client driver to access its database. Hope this is somehow answering your question. --francois On Thu, Feb 5, 2009 at 7:51 AM, DerbyNoob <thestarchi...@hotmail.com> wrote: > > Hi, > > I have two java applications starting in one tomcat, with each of them > using > a derby database. My question is: > is there an advantage when using the Network server with 2 databases, or is > it wiser to use 2 embbeded drivers? Are there effincency, performance or > load advantages when using the server? > -- > View this message in context: > http://www.nabble.com/Advantage-of-Derby-Network-Server-versus-Embedded-Database-tp21854157p21854157.html > Sent from the Apache Derby Developers mailing list archive at Nabble.com. > >
