Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

multi user, declaring variables 1

Status
Not open for further replies.

StylizIT

Programmer
Dec 4, 2003
62
0
0
NL
hi people, I just wanted to know if it is required to declare all variables I need troughout my program as a session variable. Cause right now most of the forms in my application are using session variables.
But I'm wondering if it is a good thing or a bad thing to use so many session variables.

And if I have for example this code that's behind a button:

dim test1, test2, test 3 etc. is it better to have it like this, or just put them all into a session veriable? What will happen if two users wil press that button at the same time and I'm not using session variables?

thanks in advance.

You can better regret that you have done something than regret the fact you done nothing
 
You need to read up on state management. Nothing in asp.net is affected by two users pushing a button at the same time, apart from application state and some other stuff, but even then you can lock this temporarily to prevent a problem.

Everything else is specific to at most the session. But you have lots of ways to approach it. In addition to application state and caching, I would look up the following.

Session State
Viewstate (this is how asp.net preserves the state of controls between postbacks, but you can also stick your own information in there)
The QueryString
Hidden Controls (similar to ViewState)

Finally, the basic rule about asp.net is that every request which is served is stateless, and you have to use one of the above techniques to preserve state if you need to.

So when you say dim test1, test 2, these variables only remain in scope for as long as the page request is being served. If this is what you need (and sometimes it is), then fine. If not, then look at state management.

Hope this helps.

Mark [openup]
 
thanks for your reply m8, I have one more question though, I've read some stuff about statemanagement. But here's the thing: if I have a from, and on that form I declare some variables which will hold data retreived form the database. What will happen then if two users request that form and have to use the declared variables at the same time. Will asp.net automatically detect that that are two different users and declare those variables for each user?

that's why I'm using session variables instead of normal ones. But I still don't know if it is necessary for all those variables. There are some that have to be associated with a users session, because at first they were declared in a module for public use, but that gave me a lot of problems. with different users requesting those variables at the same time.

don't know if you had encountered this problem before.

It's not a big deal for me to put everything in a session, but won't that use a lot of memory?


You can better regret that you have done something than regret the fact you done nothing
 
So you understand that unlike a windows app, if declare a variable at class level, it only remains in scope for as long as that request is being served?

Code:
    Dim i As Integer = 0
    Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        i += 1
        Response.Write(i.ToString)
    End Sub
Result - even for only one user, the app does not "remember" the value of i, and it never gets incremented. For more than one user, - two concurrently running requests cannot modify the variable - they each have their own "copy".

However, if you put a variable in a public module, or as a shared public member of a class, asp.net does indeed remember it until the application ends (the last session ends or times out)

However, as you've discovered, this causes concurrency problems.

A safer alternative is to use the application object. You can lock it before you use it and unlock it afterwards (forcing any other threads to wait).

Code:
Application.Lock()
        Dim i As Integer
        If Application("MyInt") Is Nothing Then
            i = 0
        Else
            i = CInt(Application("MyInt"))
        End If
        i += 1
        Application("MyInt") = i
        Application.UnLock()
        Response.Write(Application("MyInt"))

I think in answer to your question, you don't need to use session variables for everything, and yes it is bad. There is no need to, because two users cannot interfere with each others variables.

Hope this helps.



Mark [openup]
 
thanks for this information, you told me exactly what I was looking for;) thanks m8.

You can better regret that you have done something than regret the fact you done nothing
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top