Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Session variables and server resources

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Session variables and server resources

    I’m concerned about my server’s resources. I believe I read somewhere that creating a session variable consumes resources. I have a few dialogs and code pages each containing a lot of (10-30) lines of code similar to example #1.

    My question is, would or could it be to my advantage to change my lines of code such as in example #1 to example #2?

    #1) session.jsuserid = alltrim(lookupc("F",alltrim(y),"alltrim(userid)","[pathalias.adb_path]\users","userid"))

    #1) dim jsuserid as c = session.jsuserid
    ----------------------------------------------------------------------------------------
    VS immediately dimming as displayed below:

    #2) dim jsuserid as c = alltrim(lookupc("F",alltrim(y),"alltrim(userid)","[pathalias.adb_path]\users","userid"))
    Eric

    Alpha Five Websites
    longlivepuppies.com
    socialservicenetwork.com
    -------------------------------------------------
    socialservicenetwork.org

    #2
    Re: Session variables and server resources

    Bump...
    I have another thread, "I Need More Speed" (http://msgboard.alphasoftware.com/al...ad.php?t=76824) because my application seems to be sluggish on the web. I'm bumping this because I am wondering if this could be a contributing factor.
    Eric

    Alpha Five Websites
    longlivepuppies.com
    socialservicenetwork.com
    -------------------------------------------------
    socialservicenetwork.org

    Comment


      #3
      Re: Session variables and server resources

      The idea behind a session variable is that it lives on for the life of the session. Because of this, you do not need to do the lookup on every page. Are you doing the lookup every time, or only if session.jsuserid does not exist?

      -Lenny

      Lenny Forziati
      Vice President, Internet Products and Technical Services
      Alpha Software Corporation

      Comment


        #4
        Re: Session variables and server resources

        I do not use this particular lookup on every page. I know that once the session variable is created, I can use it on the other pages. But my question is, server resources wise, is it better to dim on every page OR create the session variable once and use the session.variable result on every page?

        I have hundreds of these where I am creating session.variables and am wondering if it significantly adds up.
        Eric

        Alpha Five Websites
        longlivepuppies.com
        socialservicenetwork.com
        -------------------------------------------------
        socialservicenetwork.org

        Comment


          #5
          Re: Session variables and server resources

          Creating the variable once and referring to it on every page consumes however many bytes of data is stored in session.jsuserid times the number of users that have accessed the server in the past 15 minutes. (15 minutes is the default value for the session timeout but can be changed if desired.)

          Running the lookup on every page consumes additional CPU for each page request and uses the same amount of memory* for jsuserid, but that memory is freed up as soon as the page is finished executing.

          I can't tell you definitively which is best because it depends on the specifics of your application:
          1. How much data is stored in session.jsuserid
          2. How many concurrent sessions you have
          3. How CPU intensive your lookup is


          But I can tell you that unless you are storing quite a bit of data in the session variables and you have a large number of concurrent sessions, using session variables is probably preferable to doing the lookup on every page. Memory access is fast, at least up until you use up all the physical memory and force the OS to swap out to disk.


          * In your first post, you have jsuserid = session.jsuserid. This creates a second variable with the same data, doubling the memory usage. You can instead refer directly to session.jsuerid elsewhere in your code and eliminate jsuserid.


          -Lenny
          Last edited by Lenny Forziati; 12-04-2008, 06:48 PM.

          Lenny Forziati
          Vice President, Internet Products and Technical Services
          Alpha Software Corporation

          Comment


            #6
            Re: Session variables and server resources

            Thank you Lenny. I appreciate the narrative and understand the session variable concept better.
            Eric

            Alpha Five Websites
            longlivepuppies.com
            socialservicenetwork.com
            -------------------------------------------------
            socialservicenetwork.org

            Comment


              #7
              Re: Session variables and server resources

              I am still confused:

              1. Doesn't a session variable exist on the client, and a server variable on the server, and if that's true, then why does the session variable consume server RAM.

              2. Does delete session.variable recovery ALL the RAM that was allocated to it?

              3. In a machine that has 4 GB RAM, why am I noticing significant slow downs when RAM gets just to 250K or so, and almost a crawl at 400K?
              Gary S. Traub, Ph.D.

              Comment


                #8
                Re: Session variables and server resources

                Gary,

                For comparison my server memory usage runs around 80K when not in use, and about 110K during the day through normal use, and spikes up to 150K or for specific activity. The fact that it goes back down to baseline 80-90K or so means the apps are running fine, no memory leak.

                Since you are using AlwaysUp, click Application > Report Activity > Past Week to see your CPU usage for the last week.

                If you are getting 250-400 I would think you have an application problem. But on the other hand, like I said, my usage goes up during the day with normal use. Normal for me means about 10 people online at once doing whatever. I don't know how my server would react if I had 100 on at the same time doing the same whatever. Maybe it would hit 250 or 400, I don't know.

                What is normal usage for your server? Or, does the usage creep up even if on one is using the sever, like overnight?
                Steve Wood
                See my profile on IADN

                Comment


                  #9
                  Re: Session variables and server resources

                  Regarding session vars: I'm guilty of setting my main session vars from lookups on every single page refresh. I know I can change that to only DIM and perform the lookup if the var is empty or missing. But my largest systems still only have four or five session variables; I don't over use them. I've seen some apps where absolutely everything is set in session variables, name, address, telephone numbers, etc. And also unnecessary use such as in a URL thinking that it needs to be a session var in order to carry from one page to the next.
                  Steve Wood
                  See my profile on IADN

                  Comment


                    #10
                    Re: Session variables and server resources

                    Hi Steve,

                    I have several questions:

                    1. What is the disadvantage of using session variables versus page variables?

                    2. If you redo the lookup on any page that you use the session variable on, then why do you need a session variable at all in that case?

                    3. How is a page variable used? If I have a grid, I can put a session variable with a value in the url or I can just deine the session variable in 1 of the events - it will then be available to whatever page I want, without having to put it in the url. So how would I pass the variable from the grid to a page without use of a session variable?
                    Gary S. Traub, Ph.D.

                    Comment


                      #11
                      Re: Session variables and server resources

                      I use page variables when I need the value on the target page only. Like in the URL mypage.a5w?id=abc123, I only want that "ID" to be used on the target page. I would not want it to exist generally throughout the system. A disadvantage might be just that, the value in the session var persists until you change it or delete it. If you forget this fact you might use the variable somewhere without ensuring it has the right value. An example is my Message.a5w page. The contents are entirely composed of values from three session vars. If I call that page but forget to set those values, the screen will display a message that was relevent earlier in the users session.

                      Whenever you have a dialog sitting on a page, all of the Controls are page variables. So if your dialog has a control named "Name", then when you click Submit, Name is a page variable.

                      There is no use in creating a URL like this: mypage.a5w?session.myvar=abc123. It does create a session variable that can be used on the next page, but so does mypage.a5w?myvar=abc123. Maybe just for estetics, but I never create a session var in a URL. I don't like users knowing the names of any system-wide variable where they might enjoy changing the value for fun (which they could). I might create a page variable, and then put code on the targe page converting it to a session variable if needed.

                      The only ways I know to pass a value from a grid is by creating a session var in the Events, putting the variable in the URL or writing the value to a table, and extracting it when you need it. I guess you could also set a cookie or use HTTP_POST.

                      On bullet point #2 - yep, I think that's right and over time I will change my approach to how I set session vars.

                      One more advantage of session variables. You can create __protected__ session variables that CANNOT be altered using a URL. You should know that anyone in the world can set a session or page variable in your application just by appending something like this to a valid URL "?session.myvar=somevalue". So I like protected vars because those cannot be set by a URL at all.

                      The above is also why those of you who use auto-increment values for your tables are creating a security risk. If you have a URL such as invoices.a5w?id=10001 then someone is going to manually enter invoices.a5w?id=10002 just to see if they can view someone elses invoice. I use UUID for my key field for all tables with sensitive data.
                      Steve Wood
                      See my profile on IADN

                      Comment


                        #12
                        Re: Session variables and server resources

                        Ok. Just to muddy the waters further, what is the difference between a session variable and a global variable. I understand that session vars are/can be seen by each page in your app. I know, too, that global vars can be passed from, say a dialog to a report. But beyond that? Can global vars be passed between pages? And if yes, why use session vars?
                        Peter
                        AlphaBase Solutions, LLC

                        [email protected]
                        https://www.alphabasesolutions.com


                        Comment


                          #13
                          Re: Session variables and server resources

                          Steve,

                          To me, there are MANY advantages to session variables, including the fact that they can be protected. The only reason I would think of not using them is if they are RAM hogs. So, my critical question is regarding what I asked before: how much overhead do they take, and don't they reside on the client, not the server.
                          Gary S. Traub, Ph.D.

                          Comment


                            #14
                            Re: Session variables and server resources

                            Lenny gave the answers about session overhead.

                            There are no 'global' variables on the web, only session. The only reference to global in relation to reports, if I recall correctly, is you can make a global variable in a report and then populate that variable as you generate the report from a Dialog.

                            Global is also relevent on the web when used with the Function() command.

                            But GLOBAL does not create a variable that can be passed from page to page.
                            Steve Wood
                            See my profile on IADN

                            Comment


                              #15
                              Re: Session variables and server resources

                              Originally posted by Steve Wood View Post
                              The only reference to global in relation to reports
                              That's what I thought. Thanks for bringing clarity to obscurity.
                              Peter
                              AlphaBase Solutions, LLC

                              [email protected]
                              https://www.alphabasesolutions.com


                              Comment

                              Working...
                              X