Re: Tomcat 4 JDBCRealm Connection Pooling

[Craig R. McClanahan]

On Wed, 13 Feb 2002, Glenn Nielsen wrote:

> [snip]
> The addition of GlobalNamingResources and the UserDatabase slipped below
> my radar somehow.  I looked at the latest server.xml from CVS.  I grep'd
> the docs in CVS and didn't notice anything in the docs about these yet.
>
> The addition of GlobalNamingResources and the UserDatabase does add some
> interesting possiblities when configuring resources in Tomcat 4.
>
> > (Speaking of which, we might also consider writing a JDBCUserDatabase
> > implementation as well -- that way, the admin webapp can be used to update
> > the users in a database instead of in "conf/tomcat-users.xml" like
> > MemoryUserDatabase does.)
> >
>
> How would you like to proceed with this and the JDBCDataSourceRealm?
>

I think we need both JDBCDataSourceRealm (that supports the same database
configurability as JDBCRealm) and JDBCUserDatabase (which will have to
make more stringent restrictions on the table structures in use).

> > > In addition I use a different DataSource for normal customer dB
> > > application data and realm data.  The separation of these data sources
> > > makes sure that a customer application can't be spoofed somehow to
> > > compromise the entries in the db for a realm.
> > >
> >
> > This is all easy to set up.  It's also easy to set up a scenario where a
> > single connection pool, configured in the global resources, is actually
> > shared by the JDBCDataSourceRealm and made available to an application
> > (through a ) if that is what your application requires.
> >
>
> Do you have an example of this?  I am very interested in being able to
> reduce the number of DBCP required, yet keep a complete separation of
> resources made available between virtual hosts.
>

Here's a scenario, and the way you might configure it:
- Define a connection pool in the Global JNDI resources
- Make it available to a theoretical "JDBCDataSourceRealm"
- Make it available to an application as a JNDI resource
  named "jdbc/MyDatabase".

In web.xml, the application would declare a  for the
resource named "jdbc/MyDatabase" in the usual way.

In server.xml, you would configure like this:

  




  
  
... configure the connection pool in the usual way ...
  









  ...
  
  ...



  

Doing things this way lets you substitute data source implementations
underneath either the server component (JDBCDataSourceRealm) or the
application, or change the decision about whether you are sharing the same
data source or not, without impacting any of the code that uses it.

As an additional advantage, the admin webapp will ultimately include a
nice UI to configure the global reosurces for you, plus a way to create
the resource links.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4 JDBCRealm Connection Pooling

[Craig R. McClanahan]

On Wed, 13 Feb 2002, Glenn Nielsen wrote:

> Date: Wed, 13 Feb 2002 11:53:52 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4 JDBCRealm Connection Pooling
>
> Remy Maucherat wrote:
> >
> > > On Wed, 13 Feb 2002, Glenn Nielsen wrote:
> > >
> > > Hi Glenn,
> > >
> > > Personally, I like the latter idea better (a new JDBCRealm implementation
> > > that uses a JNDI named data source) to avoid disruption of existing
> > > applications.
> >
> > Yes, I agree.
> > Internal Catalina components can now use JNDI in the HEAD branch. So the
> > DataSource could be defined in GlobalNamingResources, and the realm should
> > be able to use it. This DataSource could be shared by more components.
> >
>
> A global JDBC DataSource for Realms may work for some,
> but when virtual hosting websites and applications
> for different customers I need a different Realm for each customer.
> That way each customer has their own name space for userid's and roles.
>

You can still use JNDI resources for this -- just set up as many different
connection pools as you need (under different names), and attach the
JDBCDataSourceRealm for each application to the appropriate connection
pool name.

In the HEAD branch, I used the same basic technique for configuring the
UserDatabaseRealm in the default server.xml file.  It is configured with
the global resource name of the UserDatabase implementation to use
(default configuration value is "java:UserDatabase").  For per-host or
per-webapp user databases, I would simply set up some more of these, under
different resource names, and connect the UserDatabaseRealm for each
webapp appropriately.

(Speaking of which, we might also consider writing a JDBCUserDatabase
implementation as well -- that way, the admin webapp can be used to update
the users in a database instead of in "conf/tomcat-users.xml" like
MemoryUserDatabase does.)

> In addition I use a different DataSource for normal customer dB
> application data and realm data.  The separation of these data sources
> makes sure that a customer application can't be spoofed somehow to
> compromise the entries in the db for a realm.
>

This is all easy to set up.  It's also easy to set up a scenario where a
single connection pool, configured in the global resources, is actually
shared by the JDBCDataSourceRealm and made available to an application
(through a ) if that is what your application requires.

> Regards,
>
> Glenn
>

Craig



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

Re: Tomcat 4 JDBCRealm Connection Pooling

[Remy Maucherat]

> On Wed, 13 Feb 2002, Glenn Nielsen wrote:
>
> Hi Glenn,
>
> Personally, I like the latter idea better (a new JDBCRealm implementation
> that uses a JNDI named data source) to avoid disruption of existing
> applications.

Yes, I agree.
Internal Catalina components can now use JNDI in the HEAD branch. So the
DataSource could be defined in GlobalNamingResources, and the realm should
be able to use it. This DataSource could be shared by more components.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat 4 JDBCRealm Connection Pooling

[Ignacio J. Ortega]

> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En
> nombre de Glenn Nielsen
> Enviado el: miércoles 13 de febrero de 2002 17:25


> Should this support be added to the current JDBCRealm, or should a new
> realm be created which uses a JNDI named JDBC DataSource?
> 

I think it's better to create a new Realm ( PooledJDBCRealm ?
DataSourceRealm ? ) to conserve backwards compatibility..

Maybe inheriting from JDBCRealm have any sense? most of the config
options available in JDBCRealm are not usefull in a DataSource Realm ..


Saludos ,
Ignacio J. Ortega


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4 JDBCRealm Connection Pooling

[Craig R. McClanahan]

On Wed, 13 Feb 2002, Glenn Nielsen wrote:

> Date: Wed, 13 Feb 2002 10:25:07 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Tomcat 4 JDBCRealm Connection Pooling
>
> Currently the JDBCRealm does not use db Connection Pooling, instead
> it maintains an open connection and synchronizes use of the connection.
>
> I have been using the new Tomcat 4.1-dev DBCP for creating
> a JNDI named JDBC DataSource and it has been working well.
>
> The easiest way to implement db connection pooling may be by
> providing a JDBC Realm which uses a JNDI named JDBC DataSource.
>
> Should this support be added to the current JDBCRealm, or should a new
> realm be created which uses a JNDI named JDBC DataSource?
>

Hi Glenn,

Personally, I like the latter idea better (a new JDBCRealm implementation
that uses a JNDI named data source) to avoid disruption of existing
applications.

> Regards,
>
> Glenn
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: