Maybe silly, but thinking about concurrency issue in ASP.NET

  • Thread starter Thread starter Homa
  • Start date Start date
H

Homa

Hi,

I'm thinking what will happen if two users access a page at the same
time. If there are any local variable in the page, will this cause
concurrency problem?

Simarily, if this page need to call some functions, say
logic.doSomthing(), and the class logic is a singleton (for
simplicity), will there be problems?

Right now I'm using lock () {} to protect the class logic. Is that a
waste of time?

Please shed some light in this.

Best Regards,
Homa Wong
 
There are no concurrency issues in ASP .NET unless that one page you're
accessing is controlling/modifying a global variable or something like that
(which you shouldn't do in the first place)
 
Homa said:
Hi,

I'm thinking what will happen if two users access a page at the same
time. If there are any local variable in the page, will this cause
concurrency problem?
Click to expand...

Your page is a class, and each request gets a new instance of that class.
Two instances do not share non-static variables.
Simarily, if this page need to call some functions, say
logic.doSomthing(), and the class logic is a singleton (for
simplicity), will there be problems?
Click to expand...

Yes, because both requests will be accessing the same instance of your
"logic" object.
 
Thank you.

I'm pretty new to web programming. May any share some opinion about the
website model I'm using?

I setup my website as a 3-tiers web application.

The base is a SQL Database. I communicate to it 99% using stored
procedures.

For the Business Object layer I create some component classes, like
adminBO, customerBO, cartBO, etc.

The top layer of course is the UI.

The concurrency issue I'm thinking about is related to the Business
Objects.

For each class, I create a pool of instances and the webpages use these
BO through static functions. So the webpages don't have to worry about
the instanciation of those classes.

I structured the BO like this:

class myBO : System...Component
{
// Use ArrayList because I can't do myBO[], not native.
private static ArrayList instances;
private static object[] lockpads;
private static int maxInstance;
private static int current;

...

static myBO()
{
instances = new ArrayList(maxInstance);
... init each instance
}

private myBO(){...} // Hide away constructor

// Generic function pattern
public static [returnType] foo(args)
{
lock (lockpads[current = ++current % maxInstance])
{
myBO x = (myBO)instances[current];

// use x to do stuff

return something;
}
}
}

I understand the model I use is not completely thread safe, as two calls
might obtain the same [current] value. But due to the function execution
time is not the bottle neck, the call that unluckly get trapped in the
lock for no reason would not be too bad off.


My concern here is does this model I use is more benefical then the
standard, non-pooled version? I saved the time taken to initialize each
time, but instead spend some time in claiming the lock (also the x.abc
de-referencing)


Thankyou for your kindly replies,
Homa Wong
 
Homa said:
Am I doing some dumb thing? Getting worried.
Click to expand...

It doesn't go directly to your issue, but:

Yes, I see one thing you're doing "wrong". You're worrying about performance
before functionality. If I were you and had to spend any time at all
thinking about concurrency issues at this stage in development, I'd pick the
simplest means to not have to worry about concurrency issues and implement
that.

Later, when the program works, I'd address the performance issue. If
necessary.
 
Thank you. I understand that. But you know it's very hard not to think
about it when you think you found a solution.

Homa Wong
 
Homa said:
Thank you. I understand that. But you know it's very hard not to think
about it when you think you found a solution.
Click to expand...

It takes practice. Alternatively, it takes having a project miss a deadline
because you were tuning performance when you should have been implementing
functionality.

Not that I've ever done that, of course. :-)
 
Back
Top