Re: why not SQL Authentication?
From: Brock Allen (ballen_at_NOSPAMdevelop.com)
Date: 03/31/05
- Next message: gabe garza: "Re: why not SQL Authentication?"
- Previous message: craig.wagner_at_gmail.com: "Cannot open log for source {0} -- again"
- In reply to: gabe garza: "Re: why not SQL Authentication?"
- Next in thread: gabe garza: "Re: why not SQL Authentication?"
- Reply: gabe garza: "Re: why not SQL Authentication?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 30 Mar 2005 16:39:30 -0800
> Brock,
> If the connection string was
<snip>
> So on a web based application, connections can and are pooled based on
> the Connection String. So SQLAuthentication logins can be pooled.
I don't think anything you said there is inconsistent with what I said.
> I think reading about OLE-DB Providers would be helpful as well.
OLEDB connection pooling is dog slow compared to the managed provider connection
pooling.
> Of course with all of this, in my opinion pooling a connection is just
> the first step in having a performance enhancement system, the next
> step is caching your command objects. The command objects are the
> objects doing the actual work, over and over again.
This is specious and in fact won't buy you much (if anything). The types
of performance problems we're indirectly speaking about are caused by latency.
The trick to avoid latency is to not make the trip to the database, so in
essence you need to cache data (if possible). Connection pooling is a form
of caching, as you're avoiding the latency in establishing the connection.
Another way to avoid latency is caching data returned from the database (typically
in the HttpContext.Cache) so that the next time the data's needed you don't
need to hit the network. I don't see the benefit of caching command objects,
as they simply represent what command you'd like to issue to the database.
If you cache the command, to get the actual data you still have to call ExecuteReader()
or ExecuteNonQuery() on the command, which induces a trip to the database.
So sorry that I disagree with you, but I don't buy it.
-Brock
DevelopMentor
http://staff.develop.com/ballen
- Next message: gabe garza: "Re: why not SQL Authentication?"
- Previous message: craig.wagner_at_gmail.com: "Cannot open log for source {0} -- again"
- In reply to: gabe garza: "Re: why not SQL Authentication?"
- Next in thread: gabe garza: "Re: why not SQL Authentication?"
- Reply: gabe garza: "Re: why not SQL Authentication?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
