-----------------------------------------------------------
New Message on BDOTNET
-----------------------------------------------------------
From: SitaramanM
Message 10 in Discussion
Hi Agree with Gaurav. Did a bit of dissection myself and here are the findings(just
a superset of what gaurav has already explained). One thing that you need to note is
that the connectionstring that you pass is stored as a Key in a internal
hashtable(explained below) and corresponding to that key a connectionpool object is
stored. A HashTable Key as you know is atomic, So two strings , lets say, "ABC" and
"ACB", though might contain the same letters, just because the letters themselves are
juggled around, makes them unique in a HashTable key context. Lets see the actual
flow when a connection is made(dissection done through ILDASM and other tools[])
SQLConnection.Open method is called SQLClientPermission is instantiated(irrelevant
in our context) Check for pooling is on or not is done If it is on
SQLConnectionPoolManager.GetPooledConnection method is called passing the
ConnectionString, ConnectionOptions, ByRef Flag as parameters
IntegratedSecurity flag is checked and if it is true the userid is got from the
windows identity and concatenated to the connectionstring
SQLConnectionPoolManager._manager(of type PoolManager).FindPool() method is called
passing the connectionstring as parameter The PoolManager maintains a internal
hashtable called _map which contains the connectionstring as the key and the
ConnectionPool as the Value. For every connection pool there is one entry. The
FindPool Method here will check whether there is a ConnectionPool which matches the
exact ConnectionString by doing a simple Return
CType(Me._map(connectionstring),ConnectionPool). Here note that it is just passing
the connectionstring as the key value to the hashtable for getting the connectionpool.
So the conenctionstring is atomic and if you change the order of the parameters in
the conenectionstring, then even though they might point the same db for the same
server for the same credentials, just because the order of these entities are
different in the connectionstring, there wont be a match in the hashtable search.
For e.g. if the connectionstring is "Integrated Security=SSPI;Initial Catalog=pubs"
then for the first time this string atomically is stored in the hashtable key.
Now if another request is given for "Initial Catalog=pubs;Integrated Security=SSPI",
even though only the order has changed , the key(connectionstring ) will not be found
in the hashtable resulting in returning a null from the FindPool method Once the
FindPool method returns, either it would either have returned a ConnectionPool(if
there was an existing pool which matched the exact connectionstring ) or it will
return a null(if the connection string was different in any way, including the strings
which are just passed in different order as explained above) Let us take a case
that it returned a null A new SQLConnectionPoolControl object is instantiated
passing the (Concatenated connectionstring and the User Id ) and ConnectionOption as
parameter Call the base class(DefaultPoolControl) ctor passing the connectionstring
as parameter DefaultPoolControl is initialized The ConnectionString is
stored in a _key attribute(Will be used later) in the DefaultConnectionPool
Various values like timeout, max poolsize, minpoolsize etc are got and stored in the
DefaultPoolControl attributes The Windows UserID is again stored , now in a
userId attribute of the SQLConnectionPoolControl object if Integrated Security was
true SQLConnectionPoolManager._manager(of type PoolManager).FindOrCreatePool()
method is called passing the SQLConnectionPoolControl object (created in step 5 above)
as parameter connectionstring is got from the SQLConnectionPoolControl
object(stored in the DefaultPoolControl base class of the SQLConnectionPoolControl
class in the step marked in red bold above) Calls the FindPool method passing
this connectionstring as parameter(FindPool method behavious is explained above)
Note that FindPool will return a null(Coz either the this is the first pool to be
created or the connectionstring passed does not match any of those strings in the _map
hashtable) A Lock is obtained using Monitor.Enter FindPool method with
the connectionstring parameter is again called( This is a repeat check , called
"doubl-checked locking" and is a standard mechanism when handling thread
synchronisation. Not relevant in our context but if u need more details on
double-checked locking, check out The "Double-Checked Locking is Broken" Declaration")
A new ConnectionPool(pool1) is instantiated passing the DefaultPoolControl as
parameter to the constructor An entry is added to the _map hashtable with the
connectionstring as key and the ConnectionPool created above in step 6 as the value
[Me._map(connectionstring ) = pool1].Note here that the connectionstring is stored as
the key. So for any subsequent calls to FindPool to search and locate this
connectionpool, the exact connectionstring that is stored here has to be passed as the
key. ConnectionPool is returned So either way a ConnectionPool is created.
Once this is done the GetPooledConnection method will call the GetConnection method
of the returned ConnectionPool object. This GetConnection will return a Connection
object The Connection object thus returned will be returned from the
GetPooledConnection method Open Method will get the returned Connection object
and store it in a _internalConnection attribute
So the whole thing boils down to the internal storage of the ConnectionPool (and the
connectionstring implicitly). To summarise The List of existing pools is
maintained by a PoolManager object The PoolManager object maintains it in a
_map hashtable The Key in this hashtable is the connectionstring and the
connectionpool itself is stored as the value Whenever a pool is required,
whether it is an existing pool or a new opool is to be created should be determined
The determination logic is based on the connection string passed The passed
connectionstring is checked across the entries in the _map hashtable whih contains the
connectionstrings for the existing pools if there is an exact match then an
existing pool is used else a new pool will be created. This step is applicable
for two connection strings whose credentials, db,.server everything might be the same
yet the order in which they are declared might be different
hth
regards, sr
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you received
this message by mistake, please click the "Remove" link below. On the pre-addressed
e-mail message that opens, simply click "Send". Your e-mail address will be deleted
from this group's mailing list.
mailto:[EMAIL PROTECTED]
