You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by "Robert J. Carr" <rj...@gmail.com> on 2008/06/02 22:02:18 UTC
embedded db and connection pooling
I just set up connection pooling with an embedded derby database and
it works great. I use derby in development and frequently destroy my
database (delete it) and create anew. But now that I've been using
connection pooling, it seems tomcat is holding onto some old version
of my database in memory and not looking at this newly created (and
empty) one.
Is my only solution to restart tomcat each time I recreate my db?
Before I started connection pooling I would just redeploy my webapp,
but this now gets me into problems. Ideas?
Thanks!
Re: embedded db and connection pooling
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Robert J. Carr" <rj...@gmail.com>
To: "Derby Discussion" <de...@db.apache.org>
Sent: Monday, June 02, 2008 10:02 PM
Subject: embedded db and connection pooling
>I just set up connection pooling with an embedded derby database and
> it works great. I use derby in development and frequently destroy my
> database (delete it) and create anew. But now that I've been using
> connection pooling, it seems tomcat is holding onto some old version
> of my database in memory and not looking at this newly created (and
> empty) one.
>
> Is my only solution to restart tomcat each time I recreate my db?
> Before I started connection pooling I would just redeploy my webapp,
> but this now gets me into problems. Ideas?
Robert I almost certain you can set it up on a per webapp basis...
You going to have to look at your TC documentation or google.
ie if the pool is just for a single webapp you can set it up that way.
Probably do the context stuff in the app and not for the server etc, but
check out the tc doca and google.
I have my own pools so not practised... but its do-able
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
Re: embedded db and connection pooling
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Alan Burlison" <Al...@sun.com>
To: "Derby Discussion" <de...@db.apache.org>
Sent: Wednesday, June 04, 2008 4:23 PM
Subject: Re: embedded db and connection pooling
> Johnny Kewl wrote:
>
>> I'm not sure if the driver makes any diffs, as long as when you undeploy
>> the web app, TC lets the dB go, and when you redeploy that web app it
>> makes the new connection pool, I'm not sure the driver makes any diffs.
>> I'm guessing... but I think the core issue is to stop TC making those
>> connections "when it starts", ie it must not be global, because then it
>> holds the connections for other webapps.
>> If the driver remains visible... not sure if thats a problem, its just a
>> library in a classpath?
>
> The issue is that you don't have a truly 'stand alone, drop in & deploy'
> webapp if it requires you to install stuff into the container's lib
> directory and fiddle with the server.xml file before deploying the app.
Ah, yes true, can make the webapp pools redeployable, but what do you do for
the first webapp, and the server setup.
You right, JNDI and embedded database are actually contradictory idea's, as
far as plug and play goes.
Thanks
Re: embedded db and connection pooling
Posted by Alan Burlison <Al...@sun.com>.
Johnny Kewl wrote:
> I'm not sure if the driver makes any diffs, as long as when you undeploy
> the web app, TC lets the dB go, and when you redeploy that web app it
> makes the new connection pool, I'm not sure the driver makes any diffs.
> I'm guessing... but I think the core issue is to stop TC making those
> connections "when it starts", ie it must not be global, because then it
> holds the connections for other webapps.
> If the driver remains visible... not sure if thats a problem, its just a
> library in a classpath?
The issue is that you don't have a truly 'stand alone, drop in & deploy'
webapp if it requires you to install stuff into the container's lib
directory and fiddle with the server.xml file before deploying the app.
--
Alan Burlison
--
Re: embedded db and connection pooling
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Alan Burlison" <Al...@sun.com>
To: "Derby Discussion" <de...@db.apache.org>
Sent: Wednesday, June 04, 2008 3:07 PM
Subject: Re: embedded db and connection pooling
> Johnny Kewl wrote:
>
>> Robert, read the second paragraph... "per webapp basis"
>> This is what I think... if its set up for a global resource TC thinks you
>> using the dB across all webapps.
>> So the pool is set up and remains setup even when a new webapp is added.
>> In this case, deleting the dB and rebuilding is bad news because TC is
>> still using it.
>> But on a "per webapp" basis, you undeploy, do what you will, and on a
>> redeploy, the connections a remade for that webapp only.
>>
>> It seems to just depent on whether you have the JNDI setup in sever.xml
>> (global) or web-inf/context (webapp only)
>
> From later in that document:
>
> ----------
> Use of the JDBC Data Sources JNDI Resource Factory requires that you make
> an appropriate JDBC driver available to both Tomcat internal classes and
> to your web application. This is most easily accomplished by installing
> the driver's JAR file(s) into the $CATALINA_HOME/lib directory, which
> makes the driver available both to the resource factory and to your
> application.
> ----------
>
> So even if the connection pool is per-app, it seems that the JDBC driver
> still needs to be installed globally.
Alan... actually Robert if you try it and it does work on web-app basis,
give us some feedback ;)
I'm not sure if the driver makes any diffs, as long as when you undeploy the
web app, TC lets the dB go, and when you redeploy that web app it makes the
new connection pool, I'm not sure the driver makes any diffs.
I'm guessing... but I think the core issue is to stop TC making those
connections "when it starts", ie it must not be global, because then it
holds the connections for other webapps.
If the driver remains visible... not sure if thats a problem, its just a
library in a classpath?
Maybe?
Have to agree with the idea of independent pools, have always preferred the
extra control that gives one.
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
Re: embedded db and connection pooling
Posted by Alan Burlison <Al...@sun.com>.
Johnny Kewl wrote:
> Robert, read the second paragraph... "per webapp basis"
> This is what I think... if its set up for a global resource TC thinks
> you using the dB across all webapps.
> So the pool is set up and remains setup even when a new webapp is added.
> In this case, deleting the dB and rebuilding is bad news because TC is
> still using it.
> But on a "per webapp" basis, you undeploy, do what you will, and on a
> redeploy, the connections a remade for that webapp only.
>
> It seems to just depent on whether you have the JNDI setup in sever.xml
> (global) or web-inf/context (webapp only)
From later in that document:
----------
Use of the JDBC Data Sources JNDI Resource Factory requires that you
make an appropriate JDBC driver available to both Tomcat internal
classes and to your web application. This is most easily accomplished by
installing the driver's JAR file(s) into the $CATALINA_HOME/lib
directory, which makes the driver available both to the resource factory
and to your application.
----------
So even if the connection pool is per-app, it seems that the JDBC driver
still needs to be installed globally.
If you want to build a completely stand-alone webapp that starts up and
shuts down Derby you need to provide your own connection pool. For an
example, see the following:
Start up & shut down an embedded Derby instance:
http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fDbManager.java&revision=HEAD&name=auth
Stand-alone connection pool manager:
http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fMiniConnectionPoolManager.java&revision=HEAD&name=auth
Stand-alone DataSource:
http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthDb%2fsrc%2forg%2fopensolaris%2fauth%2fdb%2fDbDataSource.java&revision=HEAD&name=auth
Tomcat infrastructure needed to start/stop Derby & create/destroy the
connection pool:
http://auth.opensolaris.org/svn/showfile.svn?path=%2ftrunk%2fAuthWebapp%2fsrc%2fjava%2forg%2fopensolaris%2fauth%2fwebapp%2fservlet%2fAuthListener.java&revision=HEAD&name=auth
--
Alan Burlison
--
Re: embedded db and connection pooling
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Robert J. Carr" <rj...@gmail.com>
To: "Derby Discussion" <de...@db.apache.org>
Sent: Tuesday, June 03, 2008 9:04 PM
Subject: Re: embedded db and connection pooling
> Hey Kristian-
>
> Thanks for the response, here's some comments:
>
>> Do you delete the files on disk and connect to the same database (again),
>> or
>> are you creating a brand new database (with a different name /
>> directory)?
>
> I will admit that what I was doing was illogical and I never should
> have expected it to work. I was basically deleting the database files
> between deployments of my web application. Since I switched to jndi
> data sources, where tomcat now owns the connection not my web app,
> this will no longer work.
>
http://www.pinkdragon.net/doc_lib/contents/en/tomcat_6_0/jndi-resources-howto.html
Robert, read the second paragraph... "per webapp basis"
This is what I think... if its set up for a global resource TC thinks you
using the dB across all webapps.
So the pool is set up and remains setup even when a new webapp is added.
In this case, deleting the dB and rebuilding is bad news because TC is still
using it.
But on a "per webapp" basis, you undeploy, do what you will, and on a
redeploy, the connections a remade for that webapp only.
It seems to just depent on whether you have the JNDI setup in sever.xml
(global) or web-inf/context (webapp only)
Have fun...
ps if you want a independent dB pool... can steal the lib and demo code here
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
Re: embedded db and connection pooling
Posted by "Robert J. Carr" <rj...@gmail.com>.
Hey Kristian-
Thanks for the response, here's some comments:
> Do you delete the files on disk and connect to the same database (again), or
> are you creating a brand new database (with a different name / directory)?
I will admit that what I was doing was illogical and I never should
have expected it to work. I was basically deleting the database files
between deployments of my web application. Since I switched to jndi
data sources, where tomcat now owns the connection not my web app,
this will no longer work.
> In any case, I suspect you have to redeploy your data source; close all open
> connections and connection again. Maybe this is something your connection
> pool manager can do, or maybe you have to issue a redeploy command for
> Tomcat?
Right ... I guess this is what I was asking, is how to do this,
assuming this is my only alternative (which I'm pretty sure it is at
this point).
> Also, which OS and file system are you running on?
OSX.5 and HFS+.
Thanks-
Robert
Re: embedded db and connection pooling
Posted by Kristian Waagan <Kr...@Sun.COM>.
Robert J. Carr wrote:
> I just set up connection pooling with an embedded derby database and
> it works great. I use derby in development and frequently destroy my
> database (delete it) and create anew. But now that I've been using
> connection pooling, it seems tomcat is holding onto some old version
> of my database in memory and not looking at this newly created (and
> empty) one.
>
> Is my only solution to restart tomcat each time I recreate my db?
> Before I started connection pooling I would just redeploy my webapp,
> but this now gets me into problems. Ideas?
Hi Robert,
It is a bit unclear to me what you are actually doing.
Do you delete the files on disk and connect to the same database
(again), or are you creating a brand new database (with a different name
/ directory)?
In any case, I suspect you have to redeploy your data source; close all
open connections and connection again. Maybe this is something your
connection pool manager can do, or maybe you have to issue a redeploy
command for Tomcat?
Also, which OS and file system are you running on?
regards,
--
Kristian
>
> Thanks!