By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,660 Members | 1,215 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,660 IT Pros & Developers. It's quick & easy.

Question about data persistence in Public variables

P: n/a
I have a public variable that is declared in a public module. This Variable
is stored into a Session variable and used to pass data from page to page.
I am seeing on my local development box that once the variable is created
and loaded with data and stored into the session variable that on the next
aspx page, before the first line of the page load is executed, the public
variables data persists. I have not done an assignment from the session
variable into the public variable to load the memory address back. Is this
just a fluke or is this the way things are suppose to work? How does my
public variable know what memory address to use? Can anyone point me to a
white paper that describes how session variables and public variables are
handled in memory? Any input would be greatly appreciated. Thanks.

Public Module Globals
Public gSettings As GlobalSettings
End Module
Jan 20 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
KJ
The members of a module are implicitly marked Shared. What this means
is that these members have the same lifetime as Shared members. A
Shared variable has only a single lifetime, which lasts for the entire
time your application is running.

Jan 20 '06 #2

P: n/a
KJ,

Thank you for the reply. I think your not following what I am stating. I am
talking about ASP.NET code. It is my understanding ASP.NET is not in itself
stateful thus when you go from one asp page to another page your variables
need to be re-addressed to memory spaces. Session and/or Cache is used to
hold information on the IIS server from page to page. You need to assign the
Session/Cache data back into a declared variable in order to access it.
That is my understanding but it is not what I am seeing.

Steps to duplicate what I am seeing.
1) create aspx page that loads data into a public variable declared in a
public module and.saves that variable into the session with the
session("X") = Variable also place a link button on page to goto page 2.

2) Create ASPX page 2 and in debug mode set break points before you start
processing this page.

3) run page 1 click on link on page and when you hit debug link on page two
check the value of the public variable. I am seeing the data stored in it
on page one without having to do an assignment statement (i.e. public
variable = session("X")). This does not seem right to me and I am wanting
to know is this by design or is this "Feature" that should not be counted on
to work the same way every time.

Thanks again.

"KJ" <n_**********@mail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
The members of a module are implicitly marked Shared. What this means
is that these members have the same lifetime as Shared members. A
Shared variable has only a single lifetime, which lasts for the entire
time your application is running.

Jan 20 '06 #3

P: n/a
KJ
Hi Steve,

Thanks for the more detailed explanation. I will try to better state
the point I made earlier using your analogy.

The public variable you mention is implicity marked Shared. This means
that its scope is application-wide. So, once the value is initially set
by page #1, the value persists because it is a module-level member
(Shared), not an instance-level member. The runtime ensure that this is
so (try it with other module-level members).

Module-level members (Shared members) are visible across the
application domain, and this is the reason page #2 can see the value
set by page #1 (they are in the same appdomain).

You do not even need to use the session object to accomplish the
cross-page persistence of that member's value, because it is persisted
in the application domain of the asp.net application (of each page is a
part).

Jan 20 '06 #4

P: n/a
KJ,

I am only seeing the public variable data persist from page to page if it is
stored in the session variable. If I remove the Session("X") = Public
Variable on the first asp page then on the load for the second page the
Public variable has a value of Nothing.
"KJ" <n_**********@mail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
Hi Steve,

Thanks for the more detailed explanation. I will try to better state
the point I made earlier using your analogy.

The public variable you mention is implicity marked Shared. This means
that its scope is application-wide. So, once the value is initially set
by page #1, the value persists because it is a module-level member
(Shared), not an instance-level member. The runtime ensure that this is
so (try it with other module-level members).

Module-level members (Shared members) are visible across the
application domain, and this is the reason page #2 can see the value
set by page #1 (they are in the same appdomain).

You do not even need to use the session object to accomplish the
cross-page persistence of that member's value, because it is persisted
in the application domain of the asp.net application (of each page is a
part).

Jan 20 '06 #5

P: n/a
KJ
That does sound odd. I will try to replicate it at home at get back to
you. Meanwhile, if anyone else is lurking on this thread and has any
ideas...

Jan 21 '06 #6

P: n/a
KJ
Steve,

I tried the code below, but was unable to duplicate the issue. Let me
know if the code below was a valid attempt at replicating the issue.

*** code follows ***
' Module code

Module TestModule1
Public GlobalSettingsInstance As New GlobalSettings
End Module

Public Class GlobalSettings
Public Int1 As Int32 = Int32.MinValue
End Class

'aspx #1

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
GlobalSettingsInstance.Int1 = 567
'Session("GSI") = GlobalSettingsInstance 'tried with this commented
and uncommented
End Sub

Private Sub lbtnGoToPage2_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles lbtnGoToPage2.Click
Response.Redirect("TestPage2.aspx", False)
End Sub

'aspx #2
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Response.Write("Hello World") 'breakpoint here reveals .Int1 member =
567, regardless of session call in aspx #1
End Sub

Jan 22 '06 #7

P: n/a
KJ,

Sounds like you duplicated my issue in that the data is persisted topage two
Page_load without setting GlobalSettingsInstance. Having data in the
GlobalSettingsInstance before an assignment statement is counter intuitive
to me. Is this data persistence by design? If so why have I not seen any
references to it in any ASP.NET documentation as a way of persisting data
between pages? Here is a microsoft document that covers data persistence in
asp.net and nowhere in it is Public variables in a public module mentioned
as a method of persisting data between pages.
http://msdn.microsoft.com/msdnmag/is...e/default.aspx

Thanks,

Steve Mauldin


"KJ" <n_**********@mail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Steve,

I tried the code below, but was unable to duplicate the issue. Let me
know if the code below was a valid attempt at replicating the issue.

*** code follows ***
' Module code

Module TestModule1
Public GlobalSettingsInstance As New GlobalSettings
End Module

Public Class GlobalSettings
Public Int1 As Int32 = Int32.MinValue
End Class

'aspx #1

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
GlobalSettingsInstance.Int1 = 567
'Session("GSI") = GlobalSettingsInstance 'tried with this commented
and uncommented
End Sub

Private Sub lbtnGoToPage2_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles lbtnGoToPage2.Click
Response.Redirect("TestPage2.aspx", False)
End Sub

'aspx #2
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Response.Write("Hello World") 'breakpoint here reveals .Int1 member =
567, regardless of session call in aspx #1
End Sub

Jan 23 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.