static class confirmation

[Steven Blair]

Using ASP.NET 2.0 and Visual Studio 2005

I have website and a DLL attached to it (BusLayer). The class inside the
dll (also imaginatively named BusLayer) havea number of static
variables. One example:

public static connectionString;

Website is running from IIS.

Am I right in saying that this BusLayer class is shared amongst ALL
intances of my website. If I access the site from my PC, and a friend
accesses from a different PC, then we are using the same variable called
connectionString?

I ran a test and put a line of trace in the static constructor (the
whole class is static) and this line was only written out once, even
when I had multiple users access my site.

Thanks in advance.

Steven

 

[scott blood]

I think your right there, i just tried this on one of our IIS servers and
the same behaviour appeared.

I think because the connection string is not changing asp.net is intellegent
enough not to need to recreate the class for multiple users.

If you actually change the ConnectionString property and then push this out
to your live server, all users on your server will actually be forced to
refresh there current session and all there Session variables are cleared.

This is actually quite clever and will be changing a number of things on our
own website to take this behaviour into account.

Regards

 

[Steven Blair]

Yup,

Originally I was creating a new instance of BusLayer each time a user
hit the website until I discovered this.
Unfortunately, the requirements have change slightly and having one
instance of the connectionString is no longer an option. Each user could
in thoery have their own connectionString so I need to cater for this
scenario.

 

[Steven Blair]

I just re-read what you replied.

The class isn't in the Session though, I access it like:

BusLayer.connectionString;

If User 1 logged in:

connectionString = "myString1";

The if user 2 logged in:

connectionString = "myString2"; //Overwrites User 1?

 

[scott blood]

Steven,

Unfortunatly this is the same requirement we have, dependant on the systems
the user can access and the subscription level, they could and do have a
different connection string.

We at first built these into the DLL's (Assemblies) for the website, but
because the system has to stay live 24/7 we had to change this to reading
the connection string from a database because when you post new assemblies
to a live server, it causes the client side variables to be reset and the
user directed straight back to the hompage as soon as they click on a link.

Regards
Scott blood
C# Developer

 

[scott blood]

Isnt the assembly in which the class is located stored on your IIS server
and forms part of your web project?

Regards

 

[Steven Blair]

I will have to make some quick changes now. I think holding the current
users conenction string in the Session might be the best approach since
there are a number of other values I need to hold.

It also raises another question for me:

Is my dll thread safe now, since multiple users are accessing the one
instance of the class. I just hadn't considered this before since I
though each user had their own copy of the dll.

Thanks for the input on this Scott.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Am I right in saying that this BusLayer class is shared amongst ALL
intances of my website. If I access the site from my PC, and a friend
accesses from a different PC, then we are using the same variable called
connectionString?

In short, yes.

The reason is that each web app create only one appdomain, and static are
bounded to AppDomain, that;s why all your request share the same variable ,
each request is simply a new thread in your web app.

a ConnectionString is a very good candidate for static, you should assign it
only once ( in global.asax in the Application_Start ) and from there on it's
readonly. Most of the time you read the info from web.config

Remember if one of those static variables are updated during the course of
the app that you should take concurrency into consideration.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I think your right there, i just tried this on one of our IIS servers and
the same behaviour appeared.

Beware of this kind of tests, you can get just circumstantials results.

I think because the connection string is not changing asp.net is
intellegent enough not to need to recreate the class for multiple users.

Not at all ! it has nothing to do with "I guess" it has all to do with the
way static are created.

If you actually change the ConnectionString property and then push this
out to your live server, all users on your server will actually be forced
to refresh there current session and all there Session variables are
cleared.

No really, well it does has that effect but not for that reason. When you
change either your web.config or any dll (or even any file) inside your bin
directory the app is recycled. This has the consequence that all the
sessions are lost.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Yup,

Originally I was creating a new instance of BusLayer each time a user
hit the website until I discovered this.
Unfortunately, the requirements have change slightly and having one
instance of the connectionString is no longer an option. Each user could
in thoery have their own connectionString so I need to cater for this
scenario.

Why each user needs a different connectionstring?
Even if they have different privileges you can use the very same
connectionstring, it's a business rule who access what, and should therefore
be enforced in your dll.

note that if each use has a different connectionstring you cannot pool them,
hence each request will create a new connection to the DB and the
scalability of your system is not going to be good.

 

[Steven Blair]

The application is really a front for a several different Databases and
depending on the login determines the Database it needs to go to.

 

[Andy]

Why each user needs a different connectionstring?
Even if they have different privileges you can use the very same
connectionstring, it's a business rule who access what, and should therefore
be enforced in your dll.

Good security calls for security all the way up the chain, even at the
database layer.

Imagine someone got ahold of that connection string; they could now
have free reign to exectute any sql they wanted. Secuirty, to be
effective, must be present in every layer.

Andy

 

[Ignacio Machin \( .NET/ C# MVP \)]

hi

then you need a connectionstring per database

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Good security calls for security all the way up the chain, even at the
database layer.

Imagine someone got ahold of that connection string; they could now
have free reign to exectute any sql they wanted. Secuirty, to be
effective, must be present in every layer.

That's true, but creating one connection string per user using the system is
overkill, maybe creating one per role when it makes sense is a good
compromise

 

[Andy]

Ya, i'd agree with the one per role route. Ideally you can use SSPI,
but that's not always possible.