Re: Internal connection fatal error
From: William \(Bill\) Vaughn (billvaRemoveThis_at_nwlink.com)
Date: 08/02/04
- Next message: Kevin Yu [MSFT]: "Re: Transactions without setting OleDbCommand.Transaction property"
- Previous message: Ed: "Re: Please help..."
- In reply to: Max Metral: "Re: Internal connection fatal error"
- Next in thread: Max Metral: "Re: Internal connection fatal error"
- Reply: Max Metral: "Re: Internal connection fatal error"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 1 Aug 2004 20:03:06 -0700
80 connections in the pool tells me this is a heavily loaded system. Saying
that means that it's being asked to process more work than it can handle.
Think of the connection pool (number of connections in the pool) as the
system tachometer. 100 connections is "overrev". Even a heavily loaded
system should make do with far fewer connections in the pool.
Yes, if an operation fails at the server, the connection can be broken. This
is not that uncommon so your error handlers need to be prepared for it. If
the connection breaks, the connection is unusable--but the pooler will still
try to reuse it (once). Your app gets an exception when it tries to use a
broken connection, but the pooler tears it down. In ADO 2.0, the whole pool
is tossed if the pooler thinks the server has crashed and you can choose to
toss the pool on your own.
When an application "inherits" a connection, it's cleared (reset) of its
"Environment" settings so you should not have one instance inherit "stuff"
from another--UNLESS you disabled the reset mechanism to get better
performance.
hth
-- ____________________________________ William (Bill) Vaughn Author, Mentor, Consultant Microsoft MVP www.betav.com Please reply only to the newsgroup so that others can benefit. This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________ "Max Metral" <memetral@hotmail.com> wrote in message news:OCIXOr1dEHA.3864@TK2MSFTNGP10.phx.gbl... > LAN connection, which isn't especially loaded (.27% according to perfmon). > The pool stabilizes at about 80 connections under heavy load, although I > just got one of these errors with 10 in the pool. I also wonder whether > it's some sort of "dirty" connection in the pool, is this possible? i.e. > something like: > > 1) Expensive query in web page > 2) user hits stop, recordset still "in" the connection > 3) connection goes back in pool > 4) another thread gets conn > 5) conn is in weird state, all bets off (also would explain errors like > missing columns, sort of) > > I realize this kind of diagnosis is indistinguishable from guessing, but you > never know > > "William (Bill) Vaughn" <billvaRemoveThis@nwlink.com> wrote in message > news:OqP135xdEHA.384@TK2MSFTNGP10.phx.gbl... > > Turn on Perfmon and watch the connection pool. Is it constantly growing > over > > time or does it flatten out after a few minutes under load? Is the network > > stable? Are you connecting over a LAN, WAN or web? If you lose a > connection > > due to IO problems on the wire, you can get this type of exception. > > > > -- > > ____________________________________ > > William (Bill) Vaughn > > Author, Mentor, Consultant > > Microsoft MVP > > www.betav.com > > Please reply only to the newsgroup so that others can benefit. > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > __________________________________ > > > > "Max Metral" <memetral@hotmail.com> wrote in message > > news:OPsOqrmdEHA.3212@TK2MSFTNGP12.phx.gbl... > > > I've seen other posts about such errors, but never a solution. It seems > > to > > > appear randomly under load. We are pretty vigilant about "using" > > > IDataReader's and Connections, so it's pretty unlikely that we're doing > > > something outwardly wrong that would excuse this sort of behavior. The > > > stack is: > > > > > > TARGETSITE: System.Data.SqlClient.SqlDataReader > > > ExecuteReader(System.Data.CommandBehavior, > > > System.Data.SqlClient.RunBehavior, Boolean) > > > > > > STACKTRACE: at > > > System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior > > cmdBehavior, > > > RunBehavior runBehavior, Boolean returnStream) > > > at System.Data.SqlClient.SqlCommand.ExecuteReader() > > > at Web.MyPage.Page_Load(Object sender, EventArgs e) > > > <removed by me> > > > > > > Perhaps related, we also see random errors like this about columns we > KNOW > > > exist in recordsets that are being returned: > > > > > > MESSAGE: EventId > > > SOURCE: System.Data > > > TARGETSITE: Int32 GetOrdinal(System.String) > > > STACKTRACE: at System.Data.Common.FieldNameLookup.GetOrdinal(String > > > fieldName) > > > at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name) > > > at MyObject..ctor(IDataReader eventReader, EventData eventData) > > > <removed by me> > > > > > > This is definitely unacceptable behavior from ADO, SQL Server, or > both... > > No > > > code that an end user writes in a managed language should be able to > > create > > > this kind of untraceable havoc. > > > > > > Any thoughts? > > > > > > > > > > > >
- Next message: Kevin Yu [MSFT]: "Re: Transactions without setting OleDbCommand.Transaction property"
- Previous message: Ed: "Re: Please help..."
- In reply to: Max Metral: "Re: Internal connection fatal error"
- Next in thread: Max Metral: "Re: Internal connection fatal error"
- Reply: Max Metral: "Re: Internal connection fatal error"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|