db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DerbyNoob <thestarchi...@hotmail.com>
Subject Re: Advantage of Derby Network Server versus Embedded Database
Date Fri, 06 Feb 2009 13:04:37 GMT

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 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 <thestarchild3@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.

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.

View raw message