Alan Burlison <[EMAIL PROTECTED]> writes: > Alan Burlison wrote: > >>> The network server actually uses the embedded driver to perform database >>> operations, so any application running in the same JVM as the server >>> could have access to the database directly through the embedded >>> driver. In your setup, I think it would make sense to use Derby this >>> way. The servlets could access the database without doing any network >>> I/O, and thereby improving the performance, whereas the external scripts >>> could use the network client driver and don't involve Tomcat. Derby's >>> manuals call this configuration an "Embedded Server" (see >>> http://db.apache.org/derby/docs/10.3/adminguide/cadminov17524.html). >> >> I knew it worked, but I didn't know if it was correct to use the >> embedded driver in that situation. After following the link you >> sent I found the following in: >> >> http://db.apache.org/derby/docs/10.3/adminguide/radminembeddedserverex.html >> >> "The program that starts the Network Server can access the database >> by using either the embedded driver or the Network Client driver." > > One other question: If I am attaching to a derby instance that is > running inside the same JVM, should I be using the client driver or > the embedded driver? From observation the client driver works with > both "jdbc:derby://locahost/mydb" and "jdbc:derby:mydb", but should I > be using the client driver only for "jdbc:derby://locahost/mydb" and > the embedded driver for "jdbc:derby:mydb"?
You shouldn't load the client driver unless your application uses jdbc:derby://localhost/mydb. The reason why the client driver seems to work in your case, is that the server already has loaded the embedded driver. So the code that runs inside the same JVM as the server should use jdbc:derby:mydb and not load the client driver, whereas the external scripts should load the client driver and use jdbc:derby://localhost/mydb. -- Knut Anders
