Impersonation and conn pooling

[Geoffp]

In the .NET data access arch guide (patterns and
practices) its says Avoid impersonation in the middle tier
because it negates conn pooling.

Why? If you impersonate a limited number of windows users
which are actually roles(depending on the actual user of
each instance of the app), conns for the same user should
be pooled, shouldn't they? The doc does go on to say
something like this but I'm not sure what its trying to
say.

I would be grateful if someone could clarify this for me.

 

[David Browne]

In the .NET data access arch guide (patterns and
practices) its says Avoid impersonation in the middle tier
because it negates conn pooling.

Why? If you impersonate a limited number of windows users
which are actually roles(depending on the actual user of
each instance of the app), conns for the same user should
be pooled, shouldn't they? The doc does go on to say
something like this but I'm not sure what its trying to
say.

That would be fine. The recommendation is to avoid impersonating each of
hundreds of end users. If you did then each user would have her own
connection pool, and you would open far too many connections to the
database. If you just have a handfull of representative users, feel free to
impersonate them.

David

 

[Yan-Hong Huang[MSFT]]

Hello Geoffp,

Thanks for posting in the group.

This is really a good questions. To answer it, we need to make sure of some
points first:

1) If the connection string is different, a new connection pool is created.

2) If the credential of the connection is different, a new connection pool
is also created.

After getting these two points, we could understand the problem much better:

1) Why need to avoid impersonation here?
If using impersonation here, difference users have different connection
pools. That is to say, if there are 100 users, at least 100 connection
pools are created. This breaks performance and has a severe impact on
application scalability.

2) What does the following part of doc say?
In fact, the following paragraphs in the article has provided you a
workaround for it. That is, just create several special accounts for
impersonation based on roles. By doing it, there are only several
connection pools created. It could both enable impersonation and make use
of connection pool better.

Does that answer your question? If there are any questions on it, please
feel free to post here.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.