If I have a static method like

static public InsertUser(string name) { /// LLBL code to insert a user }

Sine the class is in the same AppDomin (ASP.NET) i guess all request will use the same class instance of this method so im worried about concurrency issues. Should I?

Is there any thing i should do like lock { // LLBLCODE } or is LLBL threadsafe?

Thanks in regards Anders

Anderskj1 wrote:

If I have a static method like

static public InsertUser(string name) { /// LLBL code to insert a user }

Sine the class is in the same AppDomin (ASP.NET) i guess all request will use the same class instance of this method so im worried about concurrency issues. Should I?

Is there any thing i should do like lock { // LLBLCODE } or is LLBL threadsafe?

Thanks in regards Anders

I am not a threading expert by anymeans, but I think this example will suffice. Tak your method a bit further:

1: static public InsertUser(string name) 2: { 3: UserEntity newUser = new UserEntity(); 4: newUser.IsNew = true 5: newUser.Name = name;

6: using (DataAccessAdapter adapter = new DataAccessAdapater) 7: { 8: adapter.SaveEntity(newUser) 9: } 10:}

Lets say that thread A enters the code first passing name = "Bob" and gets down to line 7. Then thread B comes into the same method passing name="Joe" and thread B makes it to line 6 before thread A gets to line 8. Then for whatever reason, .NET decides to switch control back to thread A. When thread A runs line 8 a new user will be created whose name is "Joe", and then thread B would also do the same thing (providing no other threads modify the entity)

This is my theory as to what could happen. You could use locks, mutexes or other threading mechanisms.

Anyone else please feel free to give this a thumbs up or down.

Devildog: local variables are not shared among threads when they call a static method, only static members of the class. This means that what you discuss is not true, as newUser is local. The object is created on the stackframe of the calling thread, as all other locals will (it's an object here, so a reference to the instance is in the stackframe, but that's a detail). Things go differently if you have static members in a class. These are shared among all calling threads.

It's a bit hard to test this though, but that's what I learned during various discussions with other developers about 'what's the deal with static in .NET anyway?', as there is a lot of confusion about this (please correct me if I'm wrong here)

Anders: asp.net uses generally 1 appdomain, but this gets recycled sometimes, so you can have 2 appdomains at a given point. Every request of a user is handled by a thread. This means that a static method on an object is shared among all methods.

Local variables are not shared among threads, so you can use your routine without problems, as long as you don't use static member variables in the class.

Always up for a quality answere Otis. Thanks alot. Really happy with your support and product. Keep up the good work.

Anders Jacobsen.