Way to get session variables into a non-servlet?

Discussion in 'Java' started by Nino, Mar 14, 2007.

  1. Nino

    Nino Guest

    Hello,

    I have several arrays of information that I want sorted through and
    updated. They all depend on each other, and thus need to be updated
    together. Since I use these arrays in several different JSP files, I
    want to run the logic just one time and then use the arrays for
    display purposes.

    Thus, I have decided to build a JSP waiting page that will load the
    information into the arrays, do the logic, and then redirect
    accordingly. Problem is that on the waiting page, I don't know how to
    approach the logic aspect of the setup. I am currently passing the
    arrays via session variables between my JSPs. Is there a way to get my
    session variables into a regular Java file (not a servlet call), so I
    can just call methods to do the work? Is there a way to call a servlet
    without redirecting? I hope I'm making sense. Here is a sample of my
    code:

    int uid =
    java.lang.Integer.parseInt(""+session.getAttribute("user.id"));
    LoadUserData lsd = new LoadUserData();

    String programsList[][] = lsd.getPrograms(uid,
    java.lang.Integer.parseInt(request.getParameter("ep")));
    session.setAttribute("edplan.pl", programsList);

    String requirementsList[][] = lsd.getRequirements(programsList);
    session.setAttribute("edplan.rl", requirementsList);

    String groupsList[][] = lsd.getGroups(requirementsList);
    session.setAttribute("edplan.gl", groupsList);

    String coursesList[][] = lsd.getCourses(requirementsList,
    groupsList);
    session.setAttribute("edplan.cl", coursesList);

    Right here I want to do something like this:

    RunAllLogic ral = new RunAllLogic();
    ral.sortArrays();

    sortArrays would do the work on the four arrays, save them back into
    their session, and then proceed...

    The problem with redirecting is that this is all built around a
    "Please wait while we load your information..." page...

    Hope someone can provide some insight. Feel free to ask questions if
    something doesn't make sense, or I have omitted something.

    Thanks in advance for your help,
    Nino Skilj
     
    Nino, Mar 14, 2007
    #1
    1. Advertising

  2. Nino

    Wojtek Guest

    Nino wrote :
    > Hello,
    >
    > I have several arrays of information that I want sorted through and
    > updated. They all depend on each other, and thus need to be updated
    > together. Since I use these arrays in several different JSP files, I
    > want to run the logic just one time and then use the arrays for
    > display purposes.


    A Java web application actually does run as an application. You can use
    a Singelton to hold the arrays, which the servlets can access as
    required.

    Each servlet would have a call to:
    -----------------
    Application app = Application.getInstance();
    app.getStuff();
    -----------------

    And the skeleton Aplication class:
    -----------------
    public class Application
    {
    private static Application cvApp = null;
    private static boolean cvIsInitialized = false;

    // other non-static properties

    private Application()
    {
    super();
    }

    private static synchronized Application getInstance()
    {
    if ( !cvIsInitialized )
    {
    cvApp = new Application();

    // do a bunch of setup stuff using
    // cvApp.set???

    cvIsInitialized = true;
    }

    return cvApp;
    }

    // other non-static methods
    }
    -----------------

    So the first call to getInstance will actually do all the setting up,
    and it will blck any other access to it while it works.

    Every other call will be really quick.

    --
    Wojtek :)
     
    Wojtek, Mar 14, 2007
    #2
    1. Advertising

  3. Nino

    Wojtek Guest

    Wojtek wrote :
    >
    > private static synchronized Application getInstance()


    BLAST!

    That should be:

    public static synchronized Application getInstance()
    ~~~~~~

    --
    Wojtek :)
     
    Wojtek, Mar 14, 2007
    #3
  4. Nino

    Nino Guest

    > A Java web application actually does run as an application. You can use
    > a Singelton to hold the arrays, which the servlets can access as
    > required.
    >
    > Each servlet would have a call to:
    > -----------------
    > Application app = Application.getInstance();
    > app.getStuff();



    Maybe it is just my confusion on the subject, but if I run the
    information loading code first (say when a user logs on), then I
    wouldn't need to reference the Application on each JSP, would I? It
    seems that this way the getStuff function would be running the logic
    each time the file is called...


    > And the skeleton Aplication class:
    > -----------------
    > public class Application
    > {
    > private static Application cvApp = null;
    > private static boolean cvIsInitialized = false;
    >
    > // other non-static properties
    >
    > private Application()
    > {
    > super();
    > }
    >
    > private static synchronized Application getInstance()
    > {
    > if ( !cvIsInitialized )
    > {
    > cvApp = new Application();
    >
    > // do a bunch of setup stuff using
    > // cvApp.set???


    This is part of the problem... How do I do the stuff here without
    being able to access the arrays I stored as a session variable? Is
    that what .set would do instead? Where can I find reference to .set
    and how is it used in storing information and making it accessible
    between JSP files?


    > return cvApp;


    What does cvApp hold? All the arrays?

    Sorry if I'm a little slow picking this up. I think I am stuck in the
    mindset of what I think I need and am trying to figure out how your
    solution solves my problem. Hopefully you can help clarify!

    Thanks,
    Nino
     
    Nino, Mar 14, 2007
    #4
  5. Nino

    Wojtek Guest

    Nino wrote :
    >> A Java web application actually does run as an application. You can use
    >> a Singelton to hold the arrays, which the servlets can access as
    >> required.
    >>
    >> Each servlet would have a call to:
    >> -----------------
    >> Application app = Application.getInstance();
    >> app.getStuff();

    >
    >
    > Maybe it is just my confusion on the subject, but if I run the
    > information loading code first (say when a user logs on), then I
    > wouldn't need to reference the Application on each JSP, would I? It
    > seems that this way the getStuff function would be running the logic
    > each time the file is called...


    Yes, but getStuff() returns the information which has been processed
    during the application initialization, which is done only once.

    >> // do a bunch of setup stuff using
    >> // cvApp.set???

    >
    > This is part of the problem... How do I do the stuff here without
    > being able to access the arrays I stored as a session variable? Is
    > that what .set would do instead? Where can I find reference to .set
    > and how is it used in storing information and making it accessible
    > between JSP files?


    Well, you could pass the session object, then extract the arrays from
    it:
    public static synchronized Application getInstance(HttpSession session)

    Or you could have the initialization routine generate the arrays
    without the need for a session. So instead of generating the arrays in
    the first JSP and storing them in the session, the arrays are generated
    in the initialize() method and stored in the Application object.

    >> return cvApp;

    >
    > What does cvApp hold? All the arrays?


    cvApp holds a reference to the Application object.

    The Application object holds all the information which will be accessed
    by other JSP pages (or servlets).

    --
    Wojtek :)
     
    Wojtek, Mar 14, 2007
    #5
  6. Nino

    Nino Guest

    > Well, you could pass the session object, then extract the arrays from
    > it:
    > public static synchronized Application getInstance(HttpSession session)


    I suck! I didn't realize it was that easy to pass a session object to
    a method. This was extremely helpful... Thank you so much!


    > cvApp holds a reference to the Application object.
    >
    > The Application object holds all the information which will be accessed
    > by other JSP pages (or servlets).


    What are the memory implications to hold a reference to the
    Application object as opposed to holding the information within arrays
    in a HttpSession? How would I figure that out?

    Thanks again for all your help!

    Nino
     
    Nino, Mar 19, 2007
    #6
  7. Nino

    Wojtek Guest

    Nino wrote :
    >> Well, you could pass the session object, then extract the arrays from
    >> it:
    >> public static synchronized Application getInstance(HttpSession session)

    >
    > I suck! I didn't realize it was that easy to pass a session object to
    > a method. This was extremely helpful... Thank you so much!


    Except that you really should look into generating the arrays in the
    Application object. Once.

    >> cvApp holds a reference to the Application object.
    >>
    >> The Application object holds all the information which will be accessed
    >> by other JSP pages (or servlets).

    >
    > What are the memory implications to hold a reference to the
    > Application object as opposed to holding the information within arrays
    > in a HttpSession? How would I figure that out?


    If you hold the arrays in the session, then every time that one user
    uses the JSP, the server must retrieve the session information from its
    persistent storage.

    So if that one user hits the page once, then never again, eventually
    the session will time out, and the storage requirements will go away.
    But then, when another user hits the page, the array will be
    re-created. This takes time.

    In fact, every new user to the server will create the arrays, so
    eventually you will have multiple copies of the arrays, in each user's
    session.

    If you create the arrays once in the Application object, then reference
    them, the arrays are held in the JVM memory space. Each user only gets
    a reference to the arrays rather than holding the entire array.

    So it is better to create the arrays in the Application, then reference
    them for each user.

    --
    Wojtek :)
     
    Wojtek, Mar 19, 2007
    #7
  8. Nino

    Nino Guest

    > If you hold the arrays in the session, then every time that one user
    > uses the JSP, the server must retrieve the session information from its
    > persistent storage.


    Is this pretty bad? Each page currently does a check to make sure the
    session is still active and usually makes at least one reference or
    call to the session variable... So, if I have a couple arrays and two
    variables (say the user name and their id) stored in a session, each
    time I call for the user ID, am I accessing the entire session?


    > In fact, every new user to the server will create the arrays, so
    > eventually you will have multiple copies of the arrays, in each user's
    > session.


    I guess I didn't make that very clear in my initial statement. Each
    array would be different for each user that logs on to the system. Our
    system is based on unique information for each unique user. I know
    it's a bit much, but that's our selling point. It's also why I wanted
    to get away from constant database hits for this information and thus
    am storing them in arrays. Do you think there is a better solution?
    Does the Application still make sense in this context?

    Thanks,
    Nino
     
    Nino, Mar 20, 2007
    #8
  9. Nino

    Wojtek Guest

    Nino wrote :
    >> If you hold the arrays in the session, then every time that one user
    >> uses the JSP, the server must retrieve the session information from its
    >> persistent storage.

    >
    > Is this pretty bad? Each page currently does a check to make sure the
    > session is still active and usually makes at least one reference or
    > call to the session variable... So, if I have a couple arrays and two
    > variables (say the user name and their id) stored in a session, each
    > time I call for the user ID, am I accessing the entire session?


    The application server retrieves the entire session each time. You then
    reach into the session for the information stored there.

    >> In fact, every new user to the server will create the arrays, so
    >> eventually you will have multiple copies of the arrays, in each user's
    >> session.

    >
    > I guess I didn't make that very clear in my initial statement. Each
    > array would be different for each user that logs on to the system. Our
    > system is based on unique information for each unique user. I know
    > it's a bit much, but that's our selling point. It's also why I wanted
    > to get away from constant database hits for this information and thus
    > am storing them in arrays.


    This was not clear from your first post.

    > Do you think there is a better solution?


    So when the user first logs in, you get a number of rows from the
    database, store the rows in an array, then sort the array. You then put
    the array into the session. You do this for a number of tables.

    Why are you not ordering (SQL order by/ group by) the rows in the
    database call? With proper indexes the database engine will sort and
    retrieve rows quite efficiently.

    Second, the application server probably stores session information in
    some local database. Do a Google for: tomcat session storage and read
    the results.

    Third, if you are only using some of the information in the arrays,
    rather than all the information each time, it may be better to do
    database calls rather than storing arrays in the session.

    Of course this depends on the size of the arrays. Since your initial
    retrieval and sorting takes so long that you need a "Please wait" page,
    then I assume that the arrays are quite large. If a thousand users all
    click at the same time, your memory usage may grow beyond what you have
    available.

    If (in thte future) you need to use several servers for load balancing,
    then the session information must be passed from server to server:
    - user logs in. The load balancer directs the request to ServerA.
    ServerA stores the session information in the common session storage
    database (which is probably probably on different machine)
    - the user clicks on a button. The load balancer directs the request to
    ServerB. ServerB asks the common session storage database for that
    user's session information.

    You need to run some performance tests to see the difference between
    hitting the database each time or storing in the session.

    BTW, are you using a database connection pool manager? That way you do
    not need to incur the overhead of establishing a pipe to the database
    each time. Do a Google for: proxool

    Finally, using database calls eases syncronization between what is in
    the databse vs what is in the arrays. If the user makes a change to
    their profile, you need to save it in the database. Then (using your
    system) you need to re-create the arrays. So another "Please wait"
    page.

    > Does the Application still make sense in this context?


    So since each user's information is unique to that user, no using an
    Applicaton object would not make sense.

    --
    Wojtek :)
     
    Wojtek, Mar 20, 2007
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. circuit_breaker
    Replies:
    2
    Views:
    2,048
    Jack Jia
    Apr 4, 2004
  2. DiscoStu
    Replies:
    0
    Views:
    514
    DiscoStu
    Jul 8, 2004
  3. Andrew Purser
    Replies:
    3
    Views:
    5,138
    Alex Kay
    Nov 4, 2004
  4. anita
    Replies:
    7
    Views:
    2,583
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Sep 1, 2007
  5. Replies:
    9
    Views:
    988
Loading...

Share This Page