Servlets and Sessions.

Discussions

Web tier: servlets, JSP, Web frameworks: Servlets and Sessions.

  1. Servlets and Sessions. (4 messages)

    We are developing an application using JSP/Servlets and Beans with ORACLE. We follow the MVC pattern while developing this.

    All our validations are done in the Beans. There are around 50 screens and all of them have some sort of validations which requires beans.

    One of the modules has around 20 screens and the user has to go through the 20 screens at a stretch, one after the other, (that's the way business is!)

    The question is that some of my team members feel that the session might become too huge because the user continues to navigate from one screen to another.

    Is this really an issue? Are there any articles/links that talk about the size of sessions and how to handle them?

    Any pointers will be highly appreciated.
    Thanks
    Raj

    Threaded Messages (4)

  2. Servlets and Sessions.[ Go to top ]

    Well, your point about sessions growing huge is definitely a concern. In WLS, for instance, if you are running in a clustered mode, your session data is replicated in memory and/or to a database. So, the larger your session is, the slower you system ultimately becomes.

    However, having a wizard-like interface of 20 screens is not a problem. You just have to be selective as to what you place in your session. I've always recommended to put two things in a session: a linked list of session-transaction IDs that are randomly generated. Each time a user visits a page, you generate a new random number and place it at the end of the linked list. This ID is also passed back to the browser and placed in the resulting pages's URL links. ON a subsequent request, the transaction ID will be passed back into the server. The servlet should compare the input ID to the last one on the linked list (they should be the same). If they are not the same, then this means that the user has either hit the "Refresh" button or the "Back" button. This is a flag that something might be out of whack. So, in this case, if you have 20 screens, your linked list could grow large, but not that large.

    The other thing I recommend going into a Session object is a reference to an entity EJB that is managing the workflow context of your wizard. For instance, the WLS Commerce Server has a Workflow component that manages the workflow of a system as designed by a state diagram. You ask the workflow component if a transition from one state to another is allowed and it will throw an exception if it is not. You can apply that here for your screen navigation. You can draw a state diagram for the screen navigation and the allowed paths -- you can then generate an entity workflow context EJB that mimics this. Your session will ultimately just have a reference to the EJB and the linked list. And, generally, it should never grow very large.

    Tyler
  3. Servlets and Sessions.[ Go to top ]

    Tyler,

    Can you elaborate a little bit on how to implement the linked list and how to pass the id back to the browser? I have some dificulty to figure this out myself. If you can provide some sample, that will be great.

    Richard
  4. Servlets and Sessions.[ Go to top ]

    Hi Richard-

    I know it's been a little while since I monitored my threads on here. I apologize for not getting back to you in a timely manner. Were you able to figure this out or do you still need some help?

    Tyler
  5. Servlets and Sessions.[ Go to top ]

    Just to add to Tyler's point.. here are some ideas/comments for you.

    * Have you gone through the arithmetic of how much memory you will need given your expected user load? How much $$ will it cost for that memory? For most people the answer is a tiny amount.. memory is cheap these days!

    * If memory is an issue.. what about re-creating the beans on every hit? Of course one downside to this is instantiation and garbage collection time.

    * Check out Floyd Marinescu's "Put validation in the details object" pattern on the patterns section. There he discusses some tradeoff strategies for validation.