Disposing in a sealed class

[Buddy Ackerman]

I have taken over an application that has a sealed (singleton) class for database access. I want to add a private
SQLConnection class variable and open the connection it whenever it is instantiated and close it when the class it
disposed. I do this so that I can call mutiple methods within the class without having to open a connection each time.
I implemented an IDisposable interface (and a finalize interface) but it doesn't appear to work so I'm left with open
database connections. Is it just not possible to implement IDisposable on a singleton class? Should I jsut implement
finalize (if that's even possible)?

On a side note I don't see any reason to even have the Database class be a singleton. I plan on chnaging it in the
future but I don't have time to do it now.


--Buddy

 

[Jon Skeet [C# MVP]]

I have taken over an application that has a sealed (singleton) class
for database access. I want to add a private SQLConnection class
variable and open the connection it whenever it is instantiated and
close it when the class it disposed.

That sounds very odd if it's a singleton - singletons are typically
created a single time and then left for the entire lifetime of the app.

 

[Buddy Ackerman]

That sounds very odd if it's a singleton - singletons are typically
created a single time and then left for the entire lifetime of the app.

Actually that's fine that way the entire app will use the same connection for the lifetime of the app. My only question
is the possible serialization of the calls to the singleton. If 100 users hit the site at the same time then does each
call have to wait for the previous one to finish?

 

[Guest]

It depends on how your class is handling the calls. If you create
asynchronous methods in your singleton(!!) class, then a call does not have
to wait for another call to finish.

BTW, a sealed class is not synonymous with a singleton class.

with regards,

J.v.

 

[Jon Skeet [C# MVP]]

Actually that's fine that way the entire app will use the same
connection for the lifetime of the app. My only question is the
possible serialization of the calls to the singleton. If 100 users
hit the site at the same time then does each call have to wait for
the previous one to finish?

Not unless you put some synchronization in to make that happen.
However, you won't be able to use the same connection for more than one
request at a time...

You should generally open database connections and close them as soon
as possible, and let connection pooling take care of the rest.

 

[Guest]

<quote>On a side note I don't see any reason to even have the Database class
be a singleton. I plan on chnaging it in the
future but I don't have time to do it now.</quote>


A singleton class could be useful for creating and maintaining a single
connection object because in ADO.Net database pooling is automatically
managed by ADO.Net provided the connection string does not change from the
initial string. You could create a singleton class as below since you mention
you do not have the time to do it right away
using System.Data.SqlClient;
public class DBConnect
{
private DBConnect()
{

}
private static SQLConnection obj;
public static SqlConnection SetConnection()
{
if (obj!=null)
obj=new SQLConnection("connectionString--");
return obj;
}
}

In ADO.Net, the recommended way to manage connection pool is to open a
connection and close it as soon as the app is done with its task. The Close
method implicitly calls on the dispose method as well.

With the above connection class, you could have a single connection object
and use it to open and close a connection as and when required. It is not
advisable to save and use a connection state.

Aynchronous method calls help in making a call and returning the call back
to the calling object so that the calling object can continue with its
processing and when the called method has executed a callback will notify the
calling object and the results are collected by the calling method. So, if
you want to execute multiple methods simultaneously, then you should use
asynchronous methods.

with regards,

J.v.