I believe that I read somewhere that connection pooling is done at the level that the connection is declared. (Can anyone confirm or dispute this information?) If you define a JNDI-deployed JDBC DataSource globally, connections will be pooled for all web applications. If you define a JNDI-deployed JDBC DataSource within a context, connections will be pooled at the context level. The latter implies that each context will have its own connection pool, which is probably not what you want.

If you are okay with every one of your web applications connecting to your DataSource with the same credentials, I recommend deploying the DataSource globally and linking to the DataSource within each context. You could also deploy several connections to the same database with different authentication credentials to accommodate situations where different contexts have different sets of database access requirements.

At 14:24 2003-02-04, you wrote:
I have several groups of webapps -- all webapps in the same group access the
same database. I am defining a <Resource> and <ResourceParams> in server.xml
and using JNDI to acquire a DataSource (I'm using the Jakarta Commons
database connection pool).

The question is, should I define a <Resource>/<ResourceParams> for each
webapp Context, or should I just define a single <Resource>/<ResourceParams>
for each database within the <GlobalNamingResources> element.

The former would be a lot more maintenance, since I would have multiple
copies of the <Resource>/<ResourceParams> definition for the same database
(for every webapp that used that database).  But I was wondering if there
were any advantages/disadvantages to having a single global
<Resource>/<ResourceParams> shared among a group of webapps, or each webapp
defining its own <Resource> /<ResourceParams>.

Ideally, in my case, all webapps that use the same database use the same
host, so I would define the <Resource>/<ResourceParams> within the <Host>,
but that is not permitted --- they can only be defined globally or within a
Context.

Thanks,
Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sean Dockery
[EMAIL PROTECTED]
Certified Java Web Component Developer
Certified Delphi Programmer
SBD Consultants
http://www.sbdconsultants.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to