State Persisted Without Session or Application -- Why ?

  • Thread starter Anthony P. Mancini
  • Start date
A

Anthony P. Mancini

I'm working on a proof of concept that will ultimately be deployed on a load
balancer.
For the sake of a preliminary demonstration I created a C# object and marked
it's attributes
as Public Shared Static. I also set the EnableSessions and EnableViewState
Page directives
to false. Here's the part that stumped me :

as I was moving from page to page within the demo, I accidently realized the
data I dropped
into the C# object ( on login ) was being persisted throughout the
application. At first I thought
it was using the 1.1 framework on my local machine but it also worked on
another machine
without the framework. Does anyone know how that was happening ? I'm
hoping this data
was somehow being stored on the client browser which would make session
management really
easy, not to mention very friendly with respect to a load balancer.
Althought there was no
Javascript anywhere on the pages.

Any thoughts are appreciated.

Anthony
 
V

Victor Garcia Aprea [MVP]

Hi Anthony,
I'm no vb.net expert but I believe this is equivalent to C#'s static
keyword. If so, it means that any field members you declare using it will
have a per-type storage and not a per-instance one. For example:

public class Customer {
public static int CustomerCount;
}

You can then access Customer.CustomerCount (note the type prefix). This
variable will last as long as the type that contains it (Customer in this
case). And the type itself will surely live for the entire app life (if
you're not playing with creating new AppDomains and loading assemblies into
them). Note these static members are a feature of several languages (C#,
vb.net, etc) and not a feature of ASP.NET itself (ie. Session, Viewstate,
etc).

Does this helps?

--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
Looking for insights on ASP.NET? Read my blog:
http://obies.com/vga/blog.aspx
To contact me remove 'NOSPAM'. Please post all questions to the newsgroup
 
A

Anthony P. Mancini

Hello Victor,

Thanks for responding. I believe we're on the same page but there
is a lot of room for misinterpretation so I want to make sure we don't
have a disconnect before I continue down this path.

<<

these static members are a feature of several languages (C#,
vb.net, etc) and not a feature of ASP.NET itself (ie. Session, Viewstate,
etc).

I understand static members have nothing to do with ASP.NET; since I had
sessions disabled and data was being persisted I thought maybe I accidently
tapped into the webserver's memory storage somehow (I.E. Session \
Application).
I was always led to believe browser based processing was only "alive" during
the
request \ response mechanism, other than that managing state had to be done
via XML or database storage. At first glance it appears this has a lot of
potential
for managing string \ numeric data between pages. That being said I don't
understand why so many programmers wrestle with managing data persistence
between page activity. (?)


<< I believe this is equivalent to C#'s static keyword >>

This is correct, the structure you outlined below is close to what I'm
using.

<<
the type itself will surely live for the entire app life (if
you're not playing with creating new AppDomains and loading assemblies
into
them).
Not doing anything fancy, I try to keep things as simple as possible.
However I
need to understand how \ where this data is actually being stored. I need
to make
sure I'm not creating a situation where we'll need to implement sticky
sessions on
the load balancer. Also, the data has to stay unique to the user. I.E.
can't have users
overwriting each other's data being stored in this fashion.

Thanks for your help.

Anthony
 
A

Andy Gaskell

Static members would be more like application state than session state. You
won't be able to use static members for session state because (like
application state), any changes to the static member affect all clients. If
you have more than 1 client this could be a problem :)

You may want to check this article out, it talks a little bit about session
state for multi-server ASP.NET applications.
http://support.microsoft.com/default.aspx?scid=kb;en-us;815162
 
D

David Jessee

If you defing the following class:

Public Class MyClass
Public Shared SharedVar as Integer
Public NormalVar as Integer
End Class

This class has a total of 2 Fields.
Let's say that there are 500 people connected to your web app all at once,
and they all create an instance of this class. Now here's the
Question....The Class definition has 2 Fields defined. There are 500
instances of the class.....so....all together, how many fields exist?

The answer?? 501!

There are 500 NormalVar fields (each instance contains that field) But for
all 500 instances, there is only 1 SharedVar Field. So if any class changes
that value, the change is seen by all instances. The limit of this scope,
by the way, is your AppDomain. So if you had 2 different web apps, each of
whic had a reference to the Assembly containing this type definition, and
each one had 500 Users, you'd have a total of 1002 fields in existence.
 
A

Anthony P. Mancini

Andy,

Thanks for the response. I'm familiar with that article. We're going to
deploy a real session management solution when this application goes to
production. I was hoping my discovery could be leveraged to streamline
data persistence but it doesn't appear that will be the case.

Thank you,

Anthony
 
A

Anthony P. Mancini

David Jessee said:
If you defing the following class:

Public Class MyClass
Public Shared SharedVar as Integer
Public NormalVar as Integer
End Class

This class has a total of 2 Fields.
Let's say that there are 500 people connected to your web app all at once,
and they all create an instance of this class. Now here's the
Question....The Class definition has 2 Fields defined. There are 500
instances of the class.....so....all together, how many fields exist?

The answer?? 501!

There are 500 NormalVar fields (each instance contains that field) But for
all 500 instances, there is only 1 SharedVar Field. So if any class changes
that value, the change is seen by all instances. The limit of this scope,
by the way, is your AppDomain. So if you had 2 different web apps, each of
whic had a reference to the Assembly containing this type definition, and
each one had 500 Users, you'd have a total of 1002 fields in existence.
 
A

Anthony P. Mancini

David,

Thanks for the reply. Unfortunately this doesn't work the way I hoped
it would. It's fine for the proof of concept but I wouldn't try to leverage
it for production, especially in a load balanced environment.

Thank you,

Anthony
 
V

Victor Garcia Aprea [MVP]

fashion.
Static variables will be per-app and not per-user. You won't be able to use
them in the second fashion.
They will be stored in-memory. Note that each instance of the app running on
each different server will have its own storage for the static variable.

Currently the only built-in storage option that gives you per-user storage
and can be used in a webfarm scenario without sticky sessions is Session
when used in modes OutOfProc or SQLState.

--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
Looking for insights on ASP.NET? Read my blog:
http://obies.com/vga/blog.aspx
To contact me remove 'NOSPAM'. Please post all questions to the newsgroup
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top