tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Mikusa <>
Subject Re: A pool question
Date Mon, 25 Feb 2013 14:33:28 GMT
On Feb 25, 2013, at 3:52 AM, Jukka Ruohonen wrote:

> Hello.
> A question related to pools. Background: a big application in which it is
> preferable to enforce different roles for different databases and tables. 
> This implies that there are different user names and passwords for different
> connections. As I understand, there are two options for connection pooling
> in a scheme like this:
> 	A. Create different resources for the different roles, each having
> 	   the user names and passwords defined as constants in the Tomcat
> 	   configuration files.

This would see to work best if you have a small and static number of user / password combinations.
 How you define "small" is up to you though, and would partly depend on the resources available
in your environment.

> 	B. Group the different roles into a bigger scheme and use the option
> 	   'alternateUsernameAllowed' to obtain the connections with the
> 	    specific user names and passwords.

This would seem to be a simpler approach if you have a large number of different logins or
a dynamic number of possibilities.  For example, if each user that logs in has their own DB

> Both were tested to work. But I wonder:
> 	1. The first option seems intuitively more efficient. But on the
> 	   other hand, does each Resource define its own cleaner thread?
> 	   I wouldn't want to overburden the setup with too many threads.

Personally, what would worry me the most about this setup is configuring and tuning each of
the pools.  Since they are all going to the same DB, I wouldn't want to overload the system
with too many connection, but at the same time there has to be enough in each pool to service
the needs of the application.  Plus getting this right, would seem to get trickier as you
add more pools into the mix.

> 	2. Are there any benchmarks on the option B? The plain FIFO seems
> 	   rather inefficient if there are many different users/passwords.

You might be better off rolling your own benchmarks here.  It'll take a little time, but you
can see how it performs given your specific definitions of "many different users/passwords".


> Any additional thoughts?
> - Jukka.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message