T
telysium.org
submit articles
www.telysium.org
www.telysium.org
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
S
Sami Vaaraniemi
Here's some constructive critisism: the code in the article "ADO.NET: Wasted
Lines of Code" is not exception safe. If an exception occurs during a query,
the SQL connection is leaked. The code is not robust and can result in an
application that is fragile and starts failing under load or non-ideal
conditions.
Sami
www.capehill.net
Lines of Code" is not exception safe. If an exception occurs during a query,
the SQL connection is leaked. The code is not robust and can result in an
application that is fragile and starts failing under load or non-ideal
conditions.
Sami
www.capehill.net
T
telysium.org
LOL
As you know in ASP.NET exceptions are handled at application level unless
you're the kind of programmer that uses exception handling as a means to
program (a bad habit). Know what you're talking about before you post...
As you know in ASP.NET exceptions are handled at application level unless
you're the kind of programmer that uses exception handling as a means to
program (a bad habit). Know what you're talking about before you post...
T
telysium.org
LOL
go to http://msdn.microsoft.com/library/default.asp look up "Global.asax "
Firstly you're presupposing that I am not handling exceptions. Secondly,
you don't seem to understand that exceptions are handled differently in
ASP.NET than windows forms. Exceptions in ASP.NET are ALWAYS handled even
if they are not explicitly handled by bubbling up first to page level (where
they can be handled there) then to application level and if not handled
there, handled by ASP.NET by redirecting to an error page. You could
manually dispose objects by explicit exception handling, or if exceptions
are not explicitly handled the corresponding objects are disposed by
ASP.NET. Therefore, what you're talking about makes no sense...
Care to show an example where an exception occurs and cannot be handled by
ASP.NET and as you say a connection leaks?
go to http://msdn.microsoft.com/library/default.asp look up "Global.asax "
Firstly you're presupposing that I am not handling exceptions. Secondly,
you don't seem to understand that exceptions are handled differently in
ASP.NET than windows forms. Exceptions in ASP.NET are ALWAYS handled even
if they are not explicitly handled by bubbling up first to page level (where
they can be handled there) then to application level and if not handled
there, handled by ASP.NET by redirecting to an error page. You could
manually dispose objects by explicit exception handling, or if exceptions
are not explicitly handled the corresponding objects are disposed by
ASP.NET. Therefore, what you're talking about makes no sense...
Care to show an example where an exception occurs and cannot be handled by
ASP.NET and as you say a connection leaks?
T
telysium.org
Catch the MySqlException at the page error handler or the application error
handler and dispose relevant objects. I'm tired of entertaining you. As it
seems you are too thick headed to get it, I leave it up to you to figure it
out. As you'll see the exception you're describing would occur without
using the GetData class just as well since network problems can occur
outside the control of code, but the exception is easily handled. If you're
attempting to point out that ASP.NET error handling is not capable of
handling a particular situation, then you need to direct your inquires to
Microsoft...
handler and dispose relevant objects. I'm tired of entertaining you. As it
seems you are too thick headed to get it, I leave it up to you to figure it
out. As you'll see the exception you're describing would occur without
using the GetData class just as well since network problems can occur
outside the control of code, but the exception is easily handled. If you're
attempting to point out that ASP.NET error handling is not capable of
handling a particular situation, then you need to direct your inquires to
Microsoft...
S
Sami Vaaraniemi
I must be missing something then. Care to show some sample code how an
application uses the GetData class from the article in an exception-safe way
that guarantees that the database connection is not leaked?
Sami
www.capehill.net
application uses the GetData class from the article in an exception-safe way
that guarantees that the database connection is not leaked?
Sami
www.capehill.net
T
telysium.org
look...
Disposing an object will dispose the objects it contains including
connection objects. ASP.NET garbage collects the page which contains the
GetData object which contains the connection object if an exception occurs
and you dispose the page. Disposing a connection implicitly closes it. You
do not need your below code. The points you make are applicable to a
Windows form application and should always be implemented there but are
irrelevant to what "we" have been talking about.
You seem to have realized in your last statement that this is indeed the
case. Is your method the best way? From my view no because what the page
is trying to do still failed in your hypothetical due to outside variables,
so you need to alert the user to the network failure and the page execution
has failed. Therefore, the connection would be disposed anyway. Why
dispose what will be disposed?. If the ASP.NET application fails due to
network failures to a backing store the best solution is to seek either a
better connection or better performing server host.
However, I should have implemented the code you suggest below to cover all
cases in which the class could be used since it was released for all...
Disposing an object will dispose the objects it contains including
connection objects. ASP.NET garbage collects the page which contains the
GetData object which contains the connection object if an exception occurs
and you dispose the page. Disposing a connection implicitly closes it. You
do not need your below code. The points you make are applicable to a
Windows form application and should always be implemented there but are
irrelevant to what "we" have been talking about.
You seem to have realized in your last statement that this is indeed the
case. Is your method the best way? From my view no because what the page
is trying to do still failed in your hypothetical due to outside variables,
so you need to alert the user to the network failure and the page execution
has failed. Therefore, the connection would be disposed anyway. Why
dispose what will be disposed?. If the ASP.NET application fails due to
network failures to a backing store the best solution is to seek either a
better connection or better performing server host.
However, I should have implemented the code you suggest below to cover all
cases in which the class could be used since it was released for all...
S
Sami Vaaraniemi
Okay here is some code that uses your GetData class to run a query. Assume
this is the Page_Load method in the code behind of your web page class:
private void Page_Load(object sender, System.EventArgs e)
{
GetData getData = new GetData();
// give everyone a 10 percent raise
int rc = getData.ExecuteNonQuery("update employees set salary = salary *
1.1");
}
Assume that the database is under heavy load and the query times out, or
suppose we're querying against a remote database and there is a network
error due to temporary network congestion. The end result is an exception in
the command.ExecuteNonQuery(); call that runs the query.
I can't see how to fix this so that the database connection would not be
leaked. Can you show how to fix this without changing the GetData class?
Sami
www.capehill.net
this is the Page_Load method in the code behind of your web page class:
private void Page_Load(object sender, System.EventArgs e)
{
GetData getData = new GetData();
// give everyone a 10 percent raise
int rc = getData.ExecuteNonQuery("update employees set salary = salary *
1.1");
}
Assume that the database is under heavy load and the query times out, or
suppose we're querying against a remote database and there is a network
error due to temporary network congestion. The end result is an exception in
the command.ExecuteNonQuery(); call that runs the query.
I can't see how to fix this so that the database connection would not be
leaked. Can you show how to fix this without changing the GetData class?
Sami
www.capehill.net
S
Sami Vaaraniemi
telysium.org said:Catch the MySqlException at the page error handler or the application error
handler and dispose relevant objects.
But how do I do this since the connection member in GetData is private? I
can't dispose of it from outside of the class.
I was just trying to point out that your GetData class does not allow me to
run queries in robust way that would guarantee that the database connection
is closed even if there is an exception. I'm afraid there are many less
experienced programmers out there who just copy paste the code and don't
realize there is a potential problem here.
If you want to make GetData robust then you could have it implement
IDisposable. In the Dispose method you can close the database connection.
The user would then use it like so:
using (GetData getData = new GetData())
{
int rc = getData.ExecuteNonQuery("update employees set salary = salary *
1.1");
}
ASP.NET error handling is perfectly capable of handling this situation, and
the C# using-statement is the best way of guaranteeing the timely disposal
of database connections.
Sami
www.capehill.net
T
telysium.org
That's why you dispose the page. You cannot do this in a Windows form since
you cannot dispose the application that's running. With the page object you
can. Hello are you listening? DISPOSING A CONNECTION OBJECT IMPLICITLY
CLOSES IT IMMEDIATELY dumb ass. It will be immediately closed and returned
to the pool. What you say about remaining in use and in the pool and pool
exceptions is bullshit. If explicitly disposing a page disposes it's
contained objects then connection objects are closed and returned to the
pool. You just don't get it...
If you are experiencing network load problems with a remote database, simply
wasting lines of code that does absolutely nothing extra wastes resources.
You said that in was impossible to not allow the connection object to leak.
I proved you wrong now you're steering this conversation into a direction
that will salvage your lack of knowledge. I WOULD AGREE and already have
that your approach would be the best practice although the overhead of using
IDisposable makes using simple try/catch blocks more feasible. I don't mind
admitting that some is right about something... Some have trouble doing
this. However, that wasn't your original contention. You insisted that it
was impossible to close the connection from within client code because it
was a private variable. Furthermore, you're completely wrong when you
submit that the connection would remain open after EXPLICITLY disposing the
page.
Know what you're talking about before you post...
LMFAO
Next time I reply to you, I'll be forced to speak in Ebonics so you can
understand
you cannot dispose the application that's running. With the page object you
can. Hello are you listening? DISPOSING A CONNECTION OBJECT IMPLICITLY
CLOSES IT IMMEDIATELY dumb ass. It will be immediately closed and returned
to the pool. What you say about remaining in use and in the pool and pool
exceptions is bullshit. If explicitly disposing a page disposes it's
contained objects then connection objects are closed and returned to the
pool. You just don't get it...
If you are experiencing network load problems with a remote database, simply
wasting lines of code that does absolutely nothing extra wastes resources.
You said that in was impossible to not allow the connection object to leak.
I proved you wrong now you're steering this conversation into a direction
that will salvage your lack of knowledge. I WOULD AGREE and already have
that your approach would be the best practice although the overhead of using
IDisposable makes using simple try/catch blocks more feasible. I don't mind
admitting that some is right about something... Some have trouble doing
this. However, that wasn't your original contention. You insisted that it
was impossible to close the connection from within client code because it
was a private variable. Furthermore, you're completely wrong when you
submit that the connection would remain open after EXPLICITLY disposing the
page.
Know what you're talking about before you post...
LMFAO
Next time I reply to you, I'll be forced to speak in Ebonics so you can
understand
C
clintonG
After reading through this thread I would say that it is not a good idea
to talk down to other developers who disagree or may not have mastered
a specific aspect of the way the technology functions if you want to
generate interest in your web site.
--
<%= Clinton Gallagher
A/E/C Consulting, Web Design, e-Commerce Software Development
Wauwatosa, Milwaukee County, Wisconsin USA
NET (e-mail address removed)
URL http://www.metromilwaukee.com/clintongallagher/
to talk down to other developers who disagree or may not have mastered
a specific aspect of the way the technology functions if you want to
generate interest in your web site.
--
<%= Clinton Gallagher
A/E/C Consulting, Web Design, e-Commerce Software Development
Wauwatosa, Milwaukee County, Wisconsin USA
NET (e-mail address removed)
URL http://www.metromilwaukee.com/clintongallagher/
T
telysium.org
You are right and I apologies to you, any further readers, and to the person
I've been arguing with. I have a bad tendency to get annoyed at people who
argue only to argue.
I've been arguing with. I have a bad tendency to get annoyed at people who
argue only to argue.
S
Sami Vaaraniemi
Inline:
You are right that the garbage collection will eventually dispose the
GetData object and its members but there is a big problem here: the
collection might take place 10 milliseconds from now or 10 weeks from now or
anything in between, and meanwhile the database connection will remain in
use. If another web request needs a connection and they are all in use
because the garbage collector did not run yet, the request will fail with
the "connection pool has been exchausted" exception.
Leaving an expensive resource such as a database connection for the garbage
collector to dispose counts as a resource leak. The problem will manifest
itself as occasional connection pool exceptions. Upgrading hardware is not
the proper solution; writing robust code that explicitely disposes the
resources as soon as possible is the proper solution. This point is
applicable to both Windows Forms and ASP.NET applications.
This is not my own invention. Check out ADO.NET connection pooling best
practices, section beginning "Always explicitly close your Connection or
DataReader objects". This applies to MySqlClient as well as SqlClient and
other SQL providers.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/adonetbest.asp
Sami
www.capehill.net
telysium.org said:look...
Disposing an object will dispose the objects it contains including
connection objects. ASP.NET garbage collects the page which contains the
GetData object which contains the connection object if an exception occurs
and you dispose the page. Disposing a connection implicitly closes it. You
do not need your below code. The points you make are applicable to a
Windows form application and should always be implemented there but are
irrelevant to what "we" have been talking about.
You seem to have realized in your last statement that this is indeed the
case. Is your method the best way? From my view no because what the page
is trying to do still failed in your hypothetical due to outside variables,
so you need to alert the user to the network failure and the page execution
has failed. Therefore, the connection would be disposed anyway. Why
dispose what will be disposed?. If the ASP.NET application fails due to
network failures to a backing store the best solution is to seek either a
better connection or better performing server host.
However, I should have implemented the code you suggest below to cover all
cases in which the class could be used since it was released for all...
You are right that the garbage collection will eventually dispose the
GetData object and its members but there is a big problem here: the
collection might take place 10 milliseconds from now or 10 weeks from now or
anything in between, and meanwhile the database connection will remain in
use. If another web request needs a connection and they are all in use
because the garbage collector did not run yet, the request will fail with
the "connection pool has been exchausted" exception.
Leaving an expensive resource such as a database connection for the garbage
collector to dispose counts as a resource leak. The problem will manifest
itself as occasional connection pool exceptions. Upgrading hardware is not
the proper solution; writing robust code that explicitely disposes the
resources as soon as possible is the proper solution. This point is
applicable to both Windows Forms and ASP.NET applications.
This is not my own invention. Check out ADO.NET connection pooling best
practices, section beginning "Always explicitly close your Connection or
DataReader objects". This applies to MySqlClient as well as SqlClient and
other SQL providers.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/adonetbest.asp
Sami
www.capehill.net
J
Joerg Jooss
telysium.org said:That's why you dispose the page. You cannot do this in a Windows
form since you cannot dispose the application that's running. With
the page object you can. Hello are you listening? DISPOSING A
CONNECTION OBJECT IMPLICITLY CLOSES IT IMMEDIATELY dumb ass. It will
be immediately closed and returned to the pool.
Unfortunately, because of *non-determinsitic* GC, you have no idea when and
if that will ever happen. It is plain wrong not to release unmanaged and
scarce resources immediately.
What you say about
remaining in use and in the pool and pool exceptions is bullshit.
Oh oh...
T
telysium.org
Disposing a connection closes it and returns it to the pool it is not GC'd
unless marked so by the pool. God why won't people friggin figure it out?
This has nothing to do with garbage collection. I QUIT!!!
One more time...
Disposing a connection calls Close() on it. This has nothing to do with
garbage collection.
unless marked so by the pool. God why won't people friggin figure it out?
This has nothing to do with garbage collection. I QUIT!!!
One more time...
Disposing a connection calls Close() on it. This has nothing to do with
garbage collection.
S
Sami Vaaraniemi
I can see you have improved the GetData class on your website. Unlike
previously, it is now robust and will not leak connections even if there is
an exception during a query. This does improve the reusability and
educational value of your class.
I'm sorry we could not get the points through to each other without less
confusion.
Sami
www.capehill.net
previously, it is now robust and will not leak connections even if there is
an exception during a query. This does improve the reusability and
educational value of your class.
I'm sorry we could not get the points through to each other without less
confusion.
Sami
www.capehill.net
T
telysium.org
I see you're are obsessed with me and my site. You're creepy...LOL
I'm sorry only you could not get the points I was making. I was right all
along and in a general sense, outside the premises of our conversation, you
were right. You just failed to see that.
I'm sorry only you could not get the points I was making. I was right all
along and in a general sense, outside the premises of our conversation, you
were right. You just failed to see that.
S
Sami Vaaraniemi
telysium.org said:I see you're are obsessed with me and my site. You're creepy...LOL
No I'm not obsessed with you or your site. It's just that I've had to fix
enough sloppy code written by others that may leak database connections and
result in a fragile website that goes on its knees under load or bad
conditions. The ADO.NET article on your site now shows robust and solid code
that under no circumstances will leak database connections. I know there's a
lot of sloppy sample code around there but maybe the solid code on your site
makes a difference and I'll have less code to fix in the future.
Sami
www.capehill.net
T
telysium.org
LMFAO whatever fag...
Sami Vaaraniemi said:No I'm not obsessed with you or your site. It's just that I've had to fix
enough sloppy code written by others that may leak database connections and
result in a fragile website that goes on its knees under load or bad
conditions. The ADO.NET article on your site now shows robust and solid code
that under no circumstances will leak database connections. I know there's a
lot of sloppy sample code around there but maybe the solid code on your site
makes a difference and I'll have less code to fix in the future.
Sami
www.capehill.net