Connection Pool Fragmentation

I was just reading
http://msdn2.microsoft.com/en-us/library/8xx3tyca(VS.80).aspx about
connection pooling with SQL server and came across the follwoing:
**************
Pool Fragmentation
Pool fragmentation is a common problem in many Web applications where the
application can create a large number of pools that are not freed until the
process exits. This leaves a large number of connections open while consumin
g
memory, resulting in poor performance.
Pool Fragmentation Due to Integrated Security
Connections are pooled according to the connection string plus the user
identity. Therefore, if you use Basic authentication or Windows
Authentication on the Web site and an integrated security login, you get one
pool per user. Although this improves the performance of subsequent database
requests for a single user, that user cannot take advantage of connections
made by other users. It also results in at least one connection per user to
the database server. This is a side effect of a particular Web application
architecture that developers need to weigh against security and auditing
requirements.
**************
I'm not sure that I understand what this really means. Can someone help me
understand?
In our environment, each user is logging into the web based app with their
own unique id, but the app connects to the db as a single login.
Tia
--
MGWhat matters is how the connection to the database is
handled. If the site is authenticating to the database using
impersonation or the app pool identity and just using the
one login, then the connection is reused. The credentials
being used are the same.
If it were setup to use delegation and integrated security,
when user A logs in one connection is used. When user B logs
in, a different connection would be used. The credentials
being used are different as one is for user A and one is for
User B. In this scenario, you need a connection for each
user.
In terms of weighing the performance vs security and
auditing, when the same credentials are used then it's that
log in that is seen in SQL Server as the user who accessed
or modified the data. You don't know the actual user, you
only know that it was the single account used by the app.
In the second scenario, SQL Server will see the access,
modification as done by the actual logged in users.
-Sue
On Fri, 10 Aug 2007 08:57:13 -0700, Hurme
<michael.geles@.thomson.com> wrote:

>I was just reading
>http://msdn2.microsoft.com/en-us/library/8xx3tyca(VS.80).aspx about
>connection pooling with SQL server and came across the follwoing:
>**************
>Pool Fragmentation
>Pool fragmentation is a common problem in many Web applications where the
>application can create a large number of pools that are not freed until the
>process exits. This leaves a large number of connections open while consumi
ng
>memory, resulting in poor performance.
>Pool Fragmentation Due to Integrated Security
>Connections are pooled according to the connection string plus the user
>identity. Therefore, if you use Basic authentication or Windows
>Authentication on the Web site and an integrated security login, you get on
e
>pool per user. Although this improves the performance of subsequent databas
e
>requests for a single user, that user cannot take advantage of connections
>made by other users. It also results in at least one connection per user to
>the database server. This is a side effect of a particular Web application
>architecture that developers need to weigh against security and auditing
>requirements.
>**************
>I'm not sure that I understand what this really means. Can someone help me
>understand?
>In our environment, each user is logging into the web based app with their
>own unique id, but the app connects to the db as a single login.
>Tiasqlsql