geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <linsun....@gmail.com>
Subject RE: developing a server wide database connection plan for oracle
Date Fri, 09 Jun 2006 14:03:35 GMT
Thanks Stan.  This has been a good derby education for me. :-)

Lin

-----Original Message-----
From: Stanley Bradbury [mailto:Stan.Bradbury@gmail.com] 
Sent: Thursday, June 08, 2006 4:18 PM
To: user@geronimo.apache.org
Subject: Re: developing a server wide database connection plan for oracle

Aaron Mulder wrote:
> I think you're OK having separate copies of the Oracle JAR loaded in
> separate applications.  I believe the problem with Derby is that it is
> (or can be) an in-memory database, and so different copies of the JAR
> in memory would have unexpected effects.
=== SNIP ==

Hi -
I want to try and clarify why Derby acts this way. Basically, it is 
because the JDBC driver *is* the database engine so there is a lot more 
going on with Derby than when other JDBC drivers are used.  So what 
happens? When you load the Derby driver for the first time within a JVM 
all the DBMS caches, lockmanager and other threads and memory structures 
are established.  The term 'embedded database' stems from this behavior; 
the DBMS system runs in the same process space as the application using 
it, the JVM. 

Contrast this to a DBMS that runs as a Server.  The DBMS is started in 
some way and waits ready to accept connections. It runs in it's own, 
isolated address space where the 'heavy duty' processing happens.  The 
primary roll of a type 4 JDBC driver in this architecture is to convert 
JDBC calls into the network protocol used by DBMS.  There should be no 
problem having two threads converting JDBC calls and sending the packets 
to a the DBMS server process. 

With Derby JDBC is the native API so no conversion of any kind is 
needed.  Since the Derby engine is right there (embedded) it goes to 
work immediately on the SQL request.  The 'heavy duty' processing goes 
on in the same address space as the application.  For Derby to function 
properly all it's classes must have access to all the internal 
structures of the DBMS system.  Classloaders can prevent this from 
happening.  Derby is at the mercy of the environment that loads it.  If 
the calling routine loads Derby in a classloader that cannot be accessed 
by Derby objects in other classloaders or visa versa unexpected 
failures, like this one, will occur.

HTH,  Stan




Mime
View raw message