<p.*********@gmail.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...
This is exactly what we are doing in our applications.
Glad to hear it.
But now we are experiencing lot of connection being open from aspnet_wp
in our Oracle database.
I'd imagine so - that's the whole point. Lots of very short connections as
opposed to a few long connections or, even worse, one persistent connection.
While we identify/correct the possible long running tasks/programming
mistakes
that can cause this issue, what I should be saying to DBA as expected when
he
queries for v$sessions.
I'd tell him that this is to be expected - what is his problem, AAMOI...?
That is where I am confused. If I have four web apps running in IIS,
connecting
to Oracle with same connection string, the ideal number of connections at
any
point should be four, am I right??
Er, no! The number of *connection pools* should be four.
When a connection is first opened, a connection pool is created based on an
exact matching algorithm that associates the pool with the connection string
in the connection. Each connection pool is associated with a distinct
connection string. When a new connection is opened, if the connection string
is not an exact match to an existing pool, a new pool is created.
Connections are pooled per process, per application domain, per connection
string and when using integrated security, per Windows identity.
When a pool is created, multiple connection objects are created and added to
the pool up to the minimum pool size value. Connections are added to the
pool as needed, up to the maximum pool size specified (default = 100).
Connections are released back into the pool when they are closed or
disposed.
When a SqlConnection object is requested, it is obtained from the pool if a
usable connection is available. To be usable, a connection must be unused,
have a matching transaction context or be unassociated with any transaction
context, and have a valid link to the server. I'd imagine this is the same
for Oracle, but don't know - sorry...
The connection pooler satisfies requests for connections by reallocating
connections as they are released back into the pool. If the maximum pool
size has been reached and no usable connection is available, the request is
queued. The pooler then tries to reclaim any connections until the timeout
is reached (default = 15 seconds). If the pooler cannot satisfy the request
before the connection times out, an exception is thrown.