Thanks Stan. This has been a good derby education for me. :-) Lin
-----Original Message----- From: Stanley Bradbury [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 4:18 PM To: [email protected] 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
