Thank you very much, that was very helpful. My 2 applications are not running in the same JVM, so I am using the Embedded Server mode. Because of SchemaUpdate Problems with Hibernate, I am using 2 different dbs of the Derby Server Instance, instead of using the one database with different schemas.
francois.orsini wrote: > > 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 <[email protected]> > 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. >> >> > > -- View this message in context: http://www.nabble.com/Advantage-of-Derby-Network-Server-versus-Embedded-Database-tp21854157p21872022.html Sent from the Apache Derby Developers mailing list archive at Nabble.com.
