tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: Tomcat 4 JDBCRealm Connection Pooling
Date Wed, 13 Feb 2002 19:24:23 GMT
"Craig R. McClanahan" wrote:
> 
> On Wed, 13 Feb 2002, Glenn Nielsen wrote:
> 
> > Date: Wed, 13 Feb 2002 11:53:52 -0600
> > From: Glenn Nielsen <glenn@voyager.apg.more.net>
> > Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> > To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> > 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.
> 

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?

> > 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 <ResourceLink>) 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.

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message