Constants and thread safety

[Paul]

Hi all,

All of the classes in my DAL are static, with constants defining the
stored procedures and parameters. I've been having some problems with
my site which makes me wonder if there's a thread safety issue.

Are consts thread safe? Would the following example create any thread
safety issues? Would you recommend using static readonly members
instead of constants?

public static class Test
{
private const string TEST_ME = "test";

public static void DoSomething()
{
AnotherStaticClass.DoSomethingElse(TEST_ME);
}
}

Thanks,

Paul

 

[Patrice]

I would start by explaining the specific issue I had. I don't see how it
could be a problem as they are read only values anyway and likely
implicitely static as a constant always provide the same value regardless of
the instance. IMO the problem you have is caused by something else...

 

[Paul]

Hi Patrice,

I'm having a buffer overrun/overflow-type issue where, when my site is
busy, the response output occasionally contains the output of
different, concurrent requests, from completely different pages. This
breaks the HTML for the current request and potentially exposes other
peoples' information.

Thanks,

Paul

 

[Patrice]

What exactly is static in your DAL ? If you have static read/write members
(method calls shouldn't be a problem if they use local data) keep in mind
that it means that this value is the same for the whole application and that
ASP.NET is a single application. That is the static value you'll set
somewhere is the one that will be available to all users...


"Paul" <[email protected]> a écrit dans le message de
(e-mail address removed)...
Hi Patrice,

I'm having a buffer overrun/overflow-type issue where, when my site is
busy, the response output occasionally contains the output of
different, concurrent requests, from completely different pages. This
breaks the HTML for the current request and potentially exposes other
peoples' information.

Thanks,

Paul

 

[Aidy]

It should be safe, but it depends what your DoSomethingElse is doing. Main
things to look at are updates to static members, references to global stores
like the Application object etc. Maybe even down to the stored proc level.

 

[Paul]

The static DAL classes just contain constants for stored procedures
and parameter names, so no class-wide data is changed.

The static methods sometimes reference HttpRuntime.Cache to cache
ILists of business model objects which, from what I understand, is
thread safe.

Thanks,

Paul

 

[Patrice]

And the keys you are using are ? If using always the same key you'll share
cached values among users as this cache is global to the application.

---
Patrice

"Paul" <[email protected]> a écrit dans le message de
(e-mail address removed)...
The static DAL classes just contain constants for stored procedures
and parameter names, so no class-wide data is changed.

The static methods sometimes reference HttpRuntime.Cache to cache
ILists of business model objects which, from what I understand, is
thread safe.

Thanks,

Paul

 

[Paul]

Yep, that's the intended behaviour, which I assume is thread safe. The
keys match the stored procedure name, which is held in a constant in
the static class.

Is there a problem doing it this way?

Thanks,

Paul

 

[Patrice]

Still not sure if you are using the same key for several users or if you
have something unique to each one. If you are using only the stored
procedure name and multiple users are using this same procedure they'll all
get to the same data (those currently in the cache)...

Could it be the problem or do you have a unique key for each user/stored
procedure ?


"Paul" <[email protected]> a écrit dans le message de
(e-mail address removed)...
Yep, that's the intended behaviour, which I assume is thread safe. The
keys match the stored procedure name, which is held in a constant in
the static class.

Is there a problem doing it this way?

Thanks,

Paul

 

[Paul]

I want users to share the same data - that's the intended behaviour.

I was just wondering if there was a problem referencing
HttpRuntime.Cache from a static class with multi-threading in mind.

Thanks,

Paul

 

[Patrice]

So if sharing those data is ok I would focus on the source of "the output of
different, concurrent requests, from completely different pages" you see in
rendered output. From where comes those unintentionaly "shared" data ?

It's likely you have something static somewhere (or scoped at application
level) and used by several users when it shouldn't.

Good luck.
---
Patrice

"Paul" <[email protected]> a écrit dans le message de
(e-mail address removed)...
I want users to share the same data - that's the intended behaviour.

I was just wondering if there was a problem referencing
HttpRuntime.Cache from a static class with multi-threading in mind.

Thanks,

Paul