Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <012d01c8c649$5faf85f0$0300000a@animal>
From: "Johnny Kewl" <john@kewlstuff.co.za>
To: "Derby Discussion" <derby-user@db.apache.org>
References: <d46327c70806021302p63cf46c1x6e7a6abba64c7910@mail.gmail.com>
 <484504EE.1010506@Sun.com>
 <d46327c70806031204k5288a679j892b8901de62910d@mail.gmail.com>
 <001501c8c63b$78bab050$0300000a@animal> <48469391.5050902@sun.com>
Subject: Re: embedded db and connection pooling
Date: Wed, 4 Jun 2008 15:46:21 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
From: "Alan Burlison" <Alan.Burlison@sun.com>
To: "Derby Discussion" <derby-user@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
---------------------------------------------------------------------------