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 WongThere 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" <homaneag@.yahoo.com> wrote in message
news:a9a6fc0b.0311111017.429c87f@.posting.google.co m...
> 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
"Homa" <homaneag@.yahoo.com> wrote in message
news:a9a6fc0b.0311111017.429c87f@.posting.google.co m...
> 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?
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?
Yes, because both requests will be accessing the same instance of your
"logic" object.
--
John
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
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Am I doing some dumb thing? Getting worried.
Homa Wong
Homa Wong <notReal@.MyWorld.com> wrote in message news:<ubbvtSOqDHA.2012@.TK2MSFTNGP12.phx.gbl>...
> 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
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!
"Homa" <homaneag@.yahoo.com> wrote in message
news:a9a6fc0b.0311131721.78494000@.posting.google.c om...
> Am I doing some dumb thing? Getting worried.
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.
--
John
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
"John Saunders" <john.saunders at surfcontrol.com> wrote in message news:<umr7VFlqDHA.2644@.TK2MSFTNGP09.phx.gbl>...
> "Homa" <homaneag@.yahoo.com> wrote in message
> news:a9a6fc0b.0311131721.78494000@.posting.google.c om...
> > Am I doing some dumb thing? Getting worried.
> 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.
"Homa" <homaneag@.yahoo.com> wrote in message
news:a9a6fc0b.0311151337.391a448d@.posting.google.c om...
> Thank you. I understand that. But you know it's very hard not to think
> about it when you think you found a solution.
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. :-)
--
John
> Homa Wong
> "John Saunders" <john.saunders at surfcontrol.com> wrote in message
news:<umr7VFlqDHA.2644@.TK2MSFTNGP09.phx.gbl>...
> > "Homa" <homaneag@.yahoo.com> wrote in message
> > news:a9a6fc0b.0311131721.78494000@.posting.google.c om...
> > > Am I doing some dumb thing? Getting worried.
> > 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.
No comments:
Post a Comment