State Persisted Without Session or Application -- Why ?

[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

[Victor Garcia Aprea [MVP]]

Hi Anthony,

Public Shared Static

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

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... 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

[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

"Victor Garcia Aprea [MVP]" <vg*@NOobiesSPAM.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl... Hi Anthony,
Public Shared Static

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

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

[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...b;en-us;815162

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:ei*************@TK2MSFTNGP11.phx.gbl...

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

"Victor Garcia Aprea [MVP]" <vg*@NOobiesSPAM.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl...

Hi Anthony,

>> Public Shared Static

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
"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

[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.

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

[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

"Andy Gaskell" <pubb AT hotmail DOT com> wrote in message
news:u9**************@TK2MSFTNGP12.phx.gbl...

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...b;en-us;815162

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:ei*************@TK2MSFTNGP11.phx.gbl...

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

"Victor Garcia Aprea [MVP]" <vg*@NOobiesSPAM.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl...

Hi Anthony,

>>> Public Shared Static
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
"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
> 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
>
>

[Anthony P. Mancini]

"David Jessee" <dj*****@houston.rr.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

[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

"David Jessee" <dj*****@houston.rr.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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.

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

[Victor Garcia Aprea [MVP]]

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.
Static variables will be per-app and not per-user. You won't be able to use
them in the second fashion.
However I need to understand how \ where
this data is actually being stored. 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

"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:ei*************@TK2MSFTNGP11.phx.gbl...

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

"Victor Garcia Aprea [MVP]" <vg*@NOobiesSPAM.com> wrote in message
news:eu**************@TK2MSFTNGP11.phx.gbl...

Hi Anthony,

>> Public Shared Static

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
"Anthony P. Mancini" <ap*@e-mancini.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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