The only reason you need to lock them is if they are making use of a static
variable which you should avoid at all costs.

I have used static methods extensively in my DAL without problems in a multi
user environment.

if you static methods use different connection is no problem.

The SqlHelper v2.0 class from Microsoft, which is considered "best practices"
code,  has all static methods. In fact, even though it first came out in
2001, I still use it extensively.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short Urls & more: http://ittyurl.net

To provide another view...I write my DAL's as non static methods.

The one reason is that I have overloaded constructors....which are
() //empty
(string dbInstanceName)

I use the Enterprise.Data library....and it allows the use of a default
"instanceName"....or you can specify a specific named instance.
"SourceDatabase"
"DesinationDatabase"

or

"VirginiaDatabase"
"TennesseeDatabase"

whatever your multiple db needs might be.

I could have done this just as easily with overloaded static methods.  But I
chose overloaded constructors instead.

..

If you are using SqlServer only...then the DAAB 2.0 is a great helper
library.

If you're using something besides Sql Server....or using SqlServer ~and~
another one...then I'd go EnterpriseLibrary.Data.

You can use the EnterpriseLibrary.Data with SqlServer only as well.  But it
has has overhead code you might not need.

If you write a really good DAL layer..you should be able to swap out DAAB
2.0 for EnterpriseLibrary.Data with little effort.

..

Check here for a sample.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
I have a 1.1 example as well, and it uses the DAAB 2.0.  Just look for it at
the blog.
(Custom Objects, ... .1.1)