Search:   Namespaces Discussions .NET v1.1 Feedback

Simultaneous SetAborts cause SqlException? Messages   Related Types This message was discovered on ASPFriends.com 'aspngescalate' list. Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions. Dan Green (VIP) I'll be really appreciative if someone could take the 5 minutes it takes (no more, I promise) to download and run the program I've linked to below. The zip file contains a .cs, .snk and build.bat file. If your database is setup with a blank password for sa, the instructions for use are: c:\temp> build.bat c:\temp> setabort.exe If you have a non-blank sa password it's the same instructions after first changing the password in the .cs file. When you run it do you see the same problem as I've described and if so, does it go away when you replace SetAbort with SetComplete? Thanks for you time. :-) --Dan --- I have a small program that creates a number of threads and on each thread calls the "byroyalty" stored procedure (via SqlClient Data Provider) on the pubs database followed by a ContextUtil.SetAbort. Some of the threads seem to fail with a SqlException. The details of the exception are: Source: SQL Server Managed Provider Number: 11 State: 0 Class: 20 Server: (LOCAL) Message: General network error. Check your network documentation. Procedure: ConnectionRead (WrapperRead()). LineNumber: 0 SQL Profiler gives the error number as 8510, which indicates the enlistment of the DTC failed. If the ContextUtil.SetAbort() is changed to a SetComplete(), however, the exceptions go away. The program can be fetched from -- http://users.bigpond.net.au/dangreen/files/setabort.zip Is there something wrong with it? Dan Green [ http://dotnetdan.com -- putting the dan in .net ] Reply to this message...        Mitch Denny (VIP) Dan, Ready for another swashbuckling .NET adventure? After a little bit of digging and some thinking I am pretty sure I understand what is going on, I even have a VERY NASTY remedy. As you probably know, the SQL provider uses connection pooling by default, all you need is the connection string to match and away you go. What appears to be happening is that when you call SetAbort() the connection is being forced down (not sure at which end yet). It might be something to do with the internal implementation of the SQLConnection class, but I think there could possibly be a bug in there somewhere where a connection is allocated from the pool early and its state not checked again. If it happens to get a connection that is getting torn down and then tries to do its thing then bingo ... no connection, therefore network error. This is all theory, and I only have limited evidence to back it up. If I slow down the speed at which threads are created (say one second between each), it has time to tear down the connection properly before the next thread requests it out of the pool. Further, if I add the "pooled=false;" parameter value combination to the connection string then it all works fine, granted, alot more memory is used, so this is that VERY NASTY remedy that I was talking about. I've had a shot at trying to find the precise error in logic by reading the IL in the System.Data.DLL assembly, if indeed that is where the error is. I can't think of anything else that might be causing this ... I hope I am wrong, and I hope there isn't anything buggy in System.Data.SqlClient.SqlConnection or the classes it wraps (like SqlInternalConnection). It is also possible that this hasn't been picked up in testing because how often do you create a huge bundle of threads and make ALL of them SetAbort(), still it should be fixed. (Hope Microsoft is listening). ---------------------------------------- - Mitch Denny - http://www.warbyte.com - Click here to reveal e-mail address - +61 (414) 610-141 - [Original message clipped] Reply to this message...        Dan Green (VIP) Mitch, Thank you for both trying and writing up your experiences! They match mine precisely. And it gets worse. I've got another example that shows yet a different kind of blow up -- http://discuss.develop.com/archives/wa.exe?A2=ind0107d&L=dotnet&F=&S=&P=3771 7 Both of these are waaaaaay too critical not to be really, really noticed and feared by anyone planning to release production code on beta 2. I'm still hoping it's just a problem with my code in both examples, but... Dan Green [ http://dotnetdan.com -- putting the dan in .net ] ----- Original Message ----- From: "Mitch Denny" <Click here to reveal e-mail address> To: "aspngescalate" <Click here to reveal e-mail address> Sent: Thursday, July 26, 2001 11:51 PM Subject: [aspngescalate] RE: Simultaneous SetAborts cause SqlException? [Original message clipped] Reply to this message...        Mitch Denny (VIP) Just following up with some more information. By tweaking the connection string you can reduce the chance of getting the error. For example, if you push the "Min Pool Size" parameter up over the number of threads you anticpate getting a transactional connection, then you should never get the problem. Combine that with a short lifetime, and you should be right. Once again, only temporary and nasty solutions. ---------------------------------------- - Mitch Denny - http://www.warbyte.com - Click here to reveal e-mail address - +61 (414) 610-141 - [Original message clipped] Reply to this message...        Mitch Denny (VIP) I haven't compiled the DOTNET sample that you posted yet, I'll do that tomorrow (we should both be sleeping now). Sometimes these are hard to pickup until you give them the acid test, and that is why there are BETA's :) ---------------------------------------- - Mitch Denny - http://www.warbyte.com - Click here to reveal e-mail address - +61 (414) 610-141 - [Original message clipped] Reply to this message...        Dan Green (VIP) [Original message clipped] My current guess (maybe we can start a competition like "guess the number of beans in the jar":-) is that the problem lies in System.EnterpriseServices.ResourcePool. Who's gonna offer up a prize for the winner? :) Dan Green [ http://dotnetdan.com -- putting the dan in .net ] Reply to this message...        Mitch Denny (VIP) Dan, I think Microsoft should be providing the prize here :) This is pure speculation (because I didn't write the code and I can't real IL _that well_), but I think you are right on the mark. I'll have to read up on the IL reference, but there looks like a Mutex is being created and released, it could be a simple threading issue in the code. Whoops! Still, we need the chaps from Microsoft to help out on this one. I sent an e-mail off to someone and I am hoping for a response shortly. ---------------------------------------- - Mitch Denny - http://www.warbyte.com - Click here to reveal e-mail address - +61 (414) 610-141 - [Original message clipped] Reply to this message...     System.Data.SqlClient.SqlConnection System.Data.SqlClient.SqlException System.EnterpriseServices.ContextUtil System.EnterpriseServices.ResourcePool Ad MBR BootFX Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd. Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com