Connection pooling & transaction context

I have been using connection pooling in a midle tier application with a very
good result. But I've always wondered what it means - when several articles
mention that the provider will divide the pool into subpools so to speak
based on transaction context among other things.
What exactly does this mean - transaction context? After all, under normal
circumstances there should be no active transaction when you close the
connection - leaving only one kind of transaction context in the pool.
Thanks in advance for any comments.
I see you haven't gotten a response on this. If you have a component based
application - like a COM+ application where multiple components in the same
transaction may open database connections, each component will open a
connection and enlist the connection in the transaction. If a connection is
already enlisted in the transaction from an earlier component running in the
same transaction it can be used without going through the enlistment
process. This saves the enlistment time and also makes commit faster
because there are fewer resource managers enlisted in the transaction.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"samse" <samse@.discussions.microsoft.com> wrote in message
news:E468BEFF-D5CC-4779-AEE0-3E0CE60F76EB@.microsoft.com...
>I have been using connection pooling in a midle tier application with a
>very
> good result. But I've always wondered what it means - when several
> articles
> mention that the provider will divide the pool into subpools so to speak
> based on transaction context among other things.
> What exactly does this mean - transaction context? After all, under normal
> circumstances there should be no active transaction when you close the
> connection - leaving only one kind of transaction context in the pool.
> Thanks in advance for any comments.