Connections as Static???

[Guest]

Hi

I am writing a fairly simple desktop app which will not be subject to great loads. Therefore this question is more for academic purposes

I have implemented a class that declares only static members and functions. I use this class to control my connections. There are just 2 methods; Open and Close. The connection object within the class is static and has public scope. It is created when the app is started. (This obviously enables connection pooling

This makes the code very simple. When I want to use a connection I just call myConnectionClass.Conn. No need to dimension anythinig, dispose etc. I just make sure I close it when the routine has finished

Is this OK? I am worried that by declaring just 1 connection as a static there will be threading issues. i.e. There may be a que of users waiting to use the single, shared connection object

What do you experts think

Andy Newland (MCAD)

 

[William Ryan eMVP]

Hi,

I am writing a fairly simple desktop app which will not be subject to

great loads. Therefore this question is more for academic purposes!

I have implemented a class that declares only static members and

functions. I use this class to control my connections. There are just 2
methods; Open and Close. The connection object within the class is static
and has public scope. It is created when the app is started. (This obviously
enables connection pooling)

If you are opening and Closing it, that's the main issue, and to the end
that you aren't leaving it open, it's ok. However, you are potentially
subjecting yourself to some problems. The way memory mgt happens with
Shared/statics is in fact different than instances but depending on how you
wrote your class, you could still accomplish this goal without creating it
as static. To be safe, you could just instantiate a new instance of the
connection inside your class and be done with it.

This makes the code very simple. When I want to use a connection I just

call myConnectionClass.Conn. No need to dimension anythinig, dispose etc. I
just make sure I close it when the routine has finished.

Is this OK? I am worried that by declaring just 1 connection as a static

there will be threading issues. i.e. There may be a que of users waiting to
use the single, shared connection object.
You could synclock it, but just physically having one connection and puttin
gthat as the ceiling does artificially limit the number of connections and
to that end, I don't think it's necessarily the way to go, particularly in
light of the fact you aren't getting much out of the deal.

 

[Guest]

Should OF COURSE of written Shared NOT static!!!!

 

[William Ryan eMVP]

In C# it's the same thing.

 

[Miha Markic [MVP C#]]

Hi Andy,

Hi,

I am writing a fairly simple desktop app which will not be subject to

great loads. Therefore this question is more for academic purposes!

I have implemented a class that declares only static members and

functions. I use this class to control my connections. There are just 2
methods; Open and Close. The connection object within the class is static
and has public scope. It is created when the app is started. (This obviously
enables connection pooling)

Does it? You have only one connection instance - there is no pooling.

This makes the code very simple. When I want to use a connection I just

call myConnectionClass.Conn. No need to dimension anythinig, dispose etc. I
just make sure I close it when the routine has finished.

Is this OK? I am worried that by declaring just 1 connection as a static

there will be threading issues. i.e. There may be a que of users waiting to
use the single, shared connection object.

Actually you will be getting exceptions since no two objects can use the
same connection instance at the same time.
You would be better of leaving the job to the ado.net - you should create a
connection instance just before you need it and close it asap.
Of course, you can still have MyConnection class or whatever but behind the
scenes you should create and dispose connection instances rather than using
shared one.