Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Caching / April 2004

Tip: Looking for answers? Try searching our database.

Thread-safe static methods/variables

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
S - 26 Apr 2004 10:28 GMT
Hi there,
I'm building an application that makes heavy use of centralized static
methods (and variables) and would just appreciate hearing someone grade my
understanding of the concept.

In probably common fashion, my static methods are typically in the DAL of my
web application. I don't have any concerns about the methods, but a lot of
collections (ArrayLists, custom collections inheriting from
System.Collections.CollectionBase, etc) are being created and passed out of
this layer. These are _not_ static collections, and my understanding is that
these are instantiated and passed out par norm, regardless of the fact that
the method itself is static. However, knowing that collections are
inherently thread-UNsafe, I still wonder about this and whether there are
exceptions to the rule or pitfalls I should be watching out for. It seems
that I shouldn't be worried about it in the capacity I've just described.
I'm pretty sure this is the case, but I'd rest easier if I could hear an
active confirmation of this..

Thanks for any advice,
S
[MSFT] - 27 Apr 2004 03:55 GMT
The returned connection object fromt the static method is not
static/shared. Generally, it is thread safe if the collection object is  
used only by one thread out of your DAL.

Hope this help,

Luke
Microsoft Online Support

Signature

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

S - 27 Apr 2004 23:12 GMT
Thanks for the reply Luke. The following response was posted over on the
framework.aspnet group, and is probably more applicable to what I'm dealing
with.. You mentioned a connection object in your post, but my case has
really nothing to do with a connection object. In my particular scenario,
I'm concerned about static methods passing non-static collections out, and
according to Paul's post, it seems these should be just fine. If you care to
add comments on Paul's post that couldn't hurt, but I think I'm seeing
things clearly now..
Thanks again,
S

"Paul Glavich [MVP - ASP.NET]" <glav@aspalliance.com-NOSPAM> wrote in
message news:<eV2FQN4KEHA.892@TK2MSFTNGP09.phx.gbl>...

> You are ok as long as nothing is shared. The collections you

> mentioined, while created/modified in a static method, are in fact

> created on the heap as per normal and although the same method can be

> accessed by multiple users (static method), the variables it creates

> are specific heap instances and therefore not shared across any static

> methods unless they themselves are static or thread statics. The DAAB

> (Data Access Application block) is based on this premise.

> So basically dont worry. All is good.

> --

> - Paul Glavich

> Microsoft MVP - ASP.NET

> The returned connection object fromt the static method is not
> static/shared. Generally, it is thread safe if the collection object is
[quoted text clipped - 8 lines]
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.