Re: Microsoft Data Access Block and static methods

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Clint (cjmueller_at_gmail.com)
Date: 12/10/04 

Date: 9 Dec 2004 22:37:00 -0800

Thanks, Scott!

The first part of your post did in fact clear up the big hangup I had
w/the MS DAL. I'd just like to try to clarify a few points, though ...
sorry for the constant questions, I just want to make sure I have this
fully understood before I make a big mistake that would cause quite a
lot of problems if data gets mixed up :)

----------
MS assumes the framework is going to be used in a multithreaded
environment and couldn't let static methods not be thread safe.
----------

So I don't have to worry about adding my own lock(...) commands when
referencing MS-written static methods, but if I'm writing my own static
methods that reference static fields in a class, I should use
lock(...)?
ie,

class Foo
{
private static string testValue;

public static void AdjustTestValue()
{
lock (this) // or lock(typeof(Foo))?
{
testValue = "something";
}
}
}

----------
That being said, instance members are not safe because a single
instance of an object is typically not going to be used by multiple
threads. In ASP.NET for instance, you typically create an instance of a
class for each user request - a TextBox control will never see multiple
threads. Since locks add some performance overhead (and a lot of
development and testing overhead), the decision makes a great deal of
sense, even if it looks counterintuitive at first.
----------

I'm having trouble understanding this ... do you mean that in an
ASP.NET (and, for my purpose, Web Services), I should be instantiating
classes instead of using statics, or that it's ok to use statics in
that each request is processed on it's own thread, so long as I don't
actually STORE a value in a static field(ex, inside the static method,
I perform a SQL query only, not storing the result of that query to a
static field)?

Thanks again!
Clint

Relevant Pages

  • Re: Microsoft Data Access Block and static methods
    ... a lock would be needed. ... >classes instead of using statics, or that it's ok to use statics in ... It is OK to use static methods in a multithreaded app, ... very careful is when using static fields. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Microsoft Data Access Block and static methods
    ... a lock would be needed. ... >classes instead of using statics, or that it's ok to use statics in ... It is OK to use static methods in a multithreaded app, ... very careful is when using static fields. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Static versus Singleton versus seperate Instantiations...
    ... Use public static methods instead of a ... > while working in a probject, you realise that some string handling stuff ... > - use a singleton structure, so that only one instance is ever created ... > I've been using public statics since the move to c# and wondered if this ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: private static
    ... For some reason I thought this wouldn't compile because the statics weren't ... >> not require an instantiation of the host class, but being private, ... > You can call private static methods from other static methods ...
    (microsoft.public.dotnet.framework.aspnet)