Altova Mailing List Archives


Re: MSXML filling up connections on IIS with SOAP?

From: sempf@----------.------
To: NULL
Date: 7/19/2006 9:46:00 AM

I have been coming to that conclusion myself, actually.  I will try the 
managed client idea and see if that makes things clearer.

S

"Alex Krawarik[MSFT]" wrote:

> So fundamentally speaking, MSXML is creating a SOAP call to ASP.NET hosted 
> on IIS, and that ASP.NET application is communicating with SQL Server, 
> calling a stored procedure, and every request that the ASP.NET application 
> makes is using a new connection to the dB, then not releasing it, something 
> like that? I don't see how the client code could be at fault, since it is 
> really just submitting an HTTP call to some arbitrary web server, right? Its 
> what the web server does with that information that results in some database 
> activity. So your issue doesnt seem like it can be attributed to MSXML code, 
> rather sounds more like your .NET web service is not releasing the database 
> resources. So
> 
> "My question is, is that a problem with the MSXML classes on the client?  I 
> mean, why would it even try to keep a connection open?  Isn't a web service 
> call a web service call?  Shouldn't it post and that's it?"
> 
> I agree with you here because HTTP is ultimately stateless; there is no 
> "connection" between web server and client during a transaction - an HTTP 
> request/response pair. A web service call (an HTTP request) is a web service 
> call (an HTTP request), and yes it should POST, get a 200 back from the 
> server and thats it.
> 
> With that in mind, it doesnt/shouldnt matter *HOW* the web server receives 
> its instructions to conect to the dB and call that SP, you will get the 
> locks no matter what. So you probably need to examine your .NET code again. 
> Perhaps write a small managed app that simply calls the API that the web 
> service wraps, and debug through it.
> 
> "Bill Sempf" <sempf@n...> wrote in message 
> news:3291DA51-D4EE-414E-BDE4-D5BF725E3247@m......
> >
> > I have an application that is using a .NET Web Service on the back end to
> > connect to a SQL Server, and a javascript page on the front end tthat
> > communicates with it using the MSXML classes.  After 20 requests, the IIS
> > server stops responsing with the "The timeout period elapsed prior to
> > obtaining a connection from the pool" error from SQL, and I have to 
> > recycle
> > the IIS app pool.
> >
> > The .NET code is clean, it doesn't leave any connections open to the
> > database, and yet after the IIS Server locks up there are 40 open locks on
> > the SQL Server, all referencing the same stored procedure.  The procedure
> > itself is very simple, so I don;t think the data code is to blame.  It 
> > really
> > seems that IIS isn;t releasing the requests from the JavaScript.
> >
> > My question is, is that a problem with the MSXML classes on the client?  I
> > mean, why would it even try to keep a connection open?  Isn't a web 
> > service
> > call a web service call?  Shouldn't it post and that's it?
> >
> > Here is the code in question.  It is from an open source learning 
> > management
> > system from 2001.
> 
> 
> 

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.