Staic Methods in a data layer object good or Bad?

  • Thread starter Thread starter Nick P.
  • Start date Start date
N

Nick P.

We have a faily large Asp.net application and we removed all of our
dat access calls to an object that just contains the actual static
calls we use against datatables and calls that execute directly
against command objects (non query calls) We wrap all of our calls
with a Mutex to avoid collisions, but we are starting to wonder if we
are asking for trouble using static calls in a web app.
can anyone shed some light on this for us? is this the way to go or
should we create individual instances of our data object when needed?
thanks
Nick P.
 
Hi Nick,

As long as static method does not use shared data there is no problem there.
However if it uses shared data then access to those data should be
thread-safe.
 
We have a faily large Asp.net application and we removed all of our
dat access calls to an object that just contains the actual static
calls we use against datatables and calls that execute directly
against command objects (non query calls) We wrap all of our calls
with a Mutex to avoid collisions, but we are starting to wonder if we
are asking for trouble using static calls in a web app.
can anyone shed some light on this for us? is this the way to go or
should we create individual instances of our data object when needed?
Click to expand...

I can't help but think you're asking the wrong question here. Static
functions aren't the issue, the real issue is static data. Static
functions don't require mutexes just because they're static.

I think the better question here is what data is requiring those
mutexes, and can you avoid it? Sometimes explicit thread coordination
in a web app is necessary, but it adds an awful lot of complexity that
is worth avoiding if possible, IMHO. For example, I'd worry a lot about
ADO.NET objects declared as static members of a class.

As an aside, I also tend to put my data access functions in a fairly
large static class, so I don't think there's anything particular faulty
about that design, I actually think it's a pretty clean way to do things.
 
David there are no static objects, that is our whole point of using a
class that contains only static functions. The Mutex is needed because
in a web app everyone shares the same thread process so you need to be
able to lock a function while one person is calling it, so there is no
collision in the thread. there is no static data and no ADO objects
are being being passed as static objects, only the function calls are
static.
Nick
 
David there are no static objects, that is our whole point of using a
class that contains only static functions. The Mutex is needed because
in a web app everyone shares the same thread process so you need to be
able to lock a function while one person is calling it, so there is no
collision in the thread.
Click to expand...

I'm 99% sure you're wrong here. That 1% is because I'm relatively new
to .NET and it's remotely possible that MS has done something incredibly
weird to make static functions non-threadsafe, but I can't for the life
of me imagine what that could be, and I find it difficult to believe
that I haven't run across anything that documents this although I've
written a lot of multithreaded .NET code in the past year.

Sure, multiple threads may be executing the same function at the same
time, but they each get their own stack frame so there's no chance of
data collision unless you've introduced one elsewhere. After all,
you've got multiple threads running the same code regardless of whether
the function is static or not (the framework doesn't make a copy of the
code for each instance of a class), so making a function static really
doesn't matter in regards to thread-safety.

But now you've got me a tad worried. If static functions are
non-threadsafe in .NET, I'd love for someone to pop in and explain why.
It just doesn't make any sense to me at all.
 
See we got bit in the butt using a static connection object. We
figured .Net would create a connection object per user, but that is
not the case. That static connection object was being shared by all
users that were logging in to the app. So all static funtions are
shared across the thread that IIS launches the app in. A mutex is
absolutely need to prevent thread collisions. we had to remove the
static object and make it an instance object when we started getting
errors related to SqlDataReaders already being open on the connection
( this being tied to SQLDataReaders that other users were acessing).
Once we make the connection object an instance variable the errors
stopped. It is all very vague to us as well, I wish someone from
Microsoft could shed some light on this for us.
Nick
 
See we got bit in the butt using a static connection object. We
figured .Net would create a connection object per user, but that is
not the case. That static connection object was being shared by all
users that were logging in to the app.
Click to expand...

Yes, a static connection object will cause problems, but that's
static *data*.
So all static funtions are
shared across the thread that IIS launches the app in.
Click to expand...

Or, more specifically, all functions may be run concurrently in multiple
IIS threads. This is true of all functions, static or not. The big
difference is that instance methods get their own copy of class
variables.
A mutex is
absolutely need to prevent thread collisions. we had to remove the
static object and make it an instance object when we started getting
errors related to SqlDataReaders already being open on the connection
( this being tied to SQLDataReaders that other users were acessing).
Once we make the connection object an instance variable the errors
stopped.
Click to expand...

Right, but again that's static data. As I said initially, you
definitely don't want to be using static/shared ADO.NET objects.
Static/shared functions are fine, static/shared objects are not
thread-safe (unless they're read-only, like a connection string). Let
me be a little more specific in code.

public static DataSet GetSomeData()
{
SqlConnection conn = new SqlConnection(conn_string);
SqlDataAdapter da = new SqlDataAdapter("SELECT...", conn);
DataSet ds = new DataSet();
da.Fill(ds);
return ds;
}

That's a static function that doesn't need to be protected by a mutex.
Even if two threads call it at exactly the same time, each will get its
own copy of the connection, adapter, etc. But...

static SqlConnection conn;

public DataSet GetSomeData()
{
conn = new SqlConnection(conn_string);
... // just like before
}

That's asking for trouble, because there's only one connection object
shared between all callers. It doesn't matter whether the *function*
is static or not, it only matters whether the data is.

So, in answer to your original question, what does your code look like?
If you've got static functions, I personally think that's a fine design
(and the mutexes aren't needed). But if your data declarations are
static, then I think you have problems. If nothing else, the necessary
mutexes are going to cause a serious bottleneck in the app.
 
Well we have no static data objects just the calls are static so we're
OK in that respect. I'm getting a little confused as far as the
mutexes are concerned. I read somewhere (seems like eons ago) that
when using static calls in a .Net web app you should use a Mutex to
avoid thread collisions. I can't remenber where I read it but I
remenber that it was the reason we incorporated using Mutexes in our
data layer. I should probably try commenting them out and seeing what
type of effect it has on our app when it's really getting hit by a lot
of users using the same functions.
 
Back
Top