Overall, the Page variables are a bad example, as the actual variable values
are stored on each client, in ViewState. If ViewState is off, then nothing
is saved on the client, so there is no issue. In reality, there is no issue
either way. Some do not like to work with ViewState.
From the way you have written this, I am not sure whether we are talking the
same thing when we say "thread safety," but I will run with the
If you write the following Class
public class SessionVars
{
public static string SessionID;
}
If you set this with user #1, and then user #2 comes in and you reset it,
both users are now effectively user #2. This is not a good thing. As such,
you need to set up instance variables (Shared = VB.NET; static = C#) on
application level properties, not on session level. I have personally seen
this happen in an application and it is not pretty. If you have instance
properties, they should be "global" in scope. I am sure someone will come up
with an exception, but learn the rule before you break it.
Another good reasoning for instances methods is helper functions. This is
more a performance issue, as loading the helper function once, in memory, is
more efficient that instancing a bunch of classes.
On the Page class (meaning your own page, which is derived from the FCL Page
class), I am fairly certain you could bump two sessions into each other with
instance methods. I cannot think of a good reason, overall, to use an
instance method, unless you have a setting for the page that should remain
static. As the weight of setting this value when creating the instance is
very low, I am not sure I can rubber stamp and instance method in a class.
If someone has a good example, I would love to see it.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
************************************************** ********************
Think Outside the Box!
************************************************** ********************
"Peter Beck" <pb***@inscapesolutions.com> wrote in message
news:Oj**************@TK2MSFTNGP09.phx.gbl...
Hi -
I have a question for someone who has experience with both ASP .Net and
JSP/Servlets, relating specifically to thread safetly.
In JSP, we say that instance vaiables of a servlet are not thread safe.
Several threads could be running the same servlet at the same time,
because a new thread of a servlet - as opposed to a new servlet itself - is
created by requests for the servlet. Since there is only one instance of the
servlet object, there is only one set of instance variables, and each
thread could set them to values that are in conflict with those in another
thread. However, you can write thread-safe servlets by avoiding instance
variables, or by judicious use of the synchronize(){ } construction.
It follows from this that instance variables in JSP pages are also not
thread safe, since the JSP is simply turned into a servlet. In theory, if
two people are running the same JSP page at the very close to the same
time the second person to access the page could re-set the value of an instance
variable to something that causes improper results for the first person,
who may be only part way through the execution of the page. I believe there
is a directive you can use to "sychronize" the whole page, although many
authorities seem to discourage this.
Can anyone tell me if there is a similar issue with ASP .Net pages,
specifically variables in the "code-behind" page? Is there something
analagous to a "servlet" that is created by ASP .Net, of which only one
copy exists that many users are executing in different threads? Is there the
possibility that users will "step on" each other's instance variables (as
there is only one instance of the object)?
Regards to all -
Peter Beck
