Is ADO.NET 2.0 reliable?

re: Is ADO.NET 2.0 reliable?

developers.de — Fri, 22 Apr 2011 14:14:43 GMT

Is ado net 2 0 reliable.. OMG! :)

re: Is ADO.NET 2.0 reliable?

Damir Dobric — Fri, 19 Oct 2007 22:08:10 GMT

Thanks for your comment Eduardo. However some people think this would be a "feature by design" :)

re: Is ADO.NET 2.0 reliable?

Eduardo — Fri, 19 Oct 2007 19:31:07 GMT

The bug must be in the Data Provider's connection pool. Probably the reader in C2 is reading data from Test3 connection.

rely and reliability

Same Old Applications — Mon, 20 Aug 2007 14:35:14 GMT

Damir Dobrić post interesting article ("Is ADO.NET reliable") on his blog about unexpected

re: Is ADO.NET 2.0 reliable?

D.Adamec — Mon, 20 Aug 2007 12:05:55 GMT

I think Damir wrote this sample as a small simplification that reproduces a problem hiding in a code deep under some DAL classes that follows usual design-paterns and guides for accessing data. And combination of factory and ADO.NET classes in multithreaded environment leads to the point where one query gets result from another query. The point is that the flawed code is here just to show us this behavior and it seems that the switching connection can jump out even when the code would be written better.

What this sample made me think of is: we all use a lot of built-in classes from many sources (core, WPF, WWF, WCF, factories, guidance packs, app blocks etc.), market push us to adopt more and more, quicker and quicker and the truth is: we should be very careful combining those bright new shiny things and putting them into our systems. For example, the book says: “Windows Workflow Foundation managing the multithreading for you so you can think of the business side of your application“. Great tip  . And of course if we combine WWF with my DAL from Ent. App block and some other XYZ new technology and put it /of course/ in a web application… we should know what we are doing ;-) … and we want to be sure that the query one will get the results of query one.

The mixture of connections from the Damir’s sample should somehow be marked at least.

re: Is ADO.NET 2.0 reliable?

Miha Markic — Mon, 20 Aug 2007 09:28:19 GMT

Hi Damir,

I think you are wrong in your assumptions. Test1 and Test2 are not thread safe because of the way connection pooling works. When you create a new instance of SqlConnection and open it you are not getting a new *physicall* connection unless pooled ones are in use. It is quite possible that your test methods all hand around a common *physicall* connection or something like that. Also take note, that when you create a multithreading mess the results aren't ones you would expect - a problem causes by inproper multithreading might corrupt whoknows which part of your application.

And BTW, my name is Miha :-)

re: Is ADO.NET 2.0 reliable?

Damir Dobric — Mon, 20 Aug 2007 09:10:00 GMT

Thanks for your comment Micha. You are right, that nobody should create such mess. However there is one thing which is a little different than you write. That is, the Threads inTest1 and Test2 are thread-safe. If they are safe, why do they not work as expected?

Developers who implemented Test1 and Test2 have nothing to do with developers who implemented buggy Test3. Test1 and Test2 were implemented in one assembly and Test3 in another one. The bad code in Test3 in reality does not look as shown in this post. This post is huge simplification of the problem.

re: Is ADO.NET 2.0 reliable?

Miha Markic — Mon, 20 Aug 2007 08:06:01 GMT

Man, your example if flawed in the beggining. You are abusing multithreading where classes used are *not* multithread safe. You are basically screwing a connection which might be reused from other threads. But what do you expect from such mutlthread bugs? Mutlithreading bugs are always hard to diagnose and might appear seemingly unrelated to the point where the error really happens.

To sum it up: your code is flawed (as you know) and expecting meaningfull errors from multithreading errors is very very optimistic.

Instead of prooving that ado.net doesn't work, you should educate the developer that created such a mess ;-)