db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Advantage of Derby Network Server versus Embedded Database
Date Thu, 05 Feb 2009 22:40:52 GMT
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.
>
>

Mime
View raw message