Storing the info other than session..?

Discussions

General J2EE: Storing the info other than session..?

  1. Storing the info other than session..? (7 messages)

    Hi, In my application we have around 5 screens for 1 functionality. In the first 4 screens the user will be entering the data and in the fifth screen we need to display the result basing on the inputs in the all the screens. We should not use sessions. So how to keep the first screen data when the user moves from first screen to second screen. and second screen data when the user moves to third from second. like this.. Since we should not use the sessions i would like to know where else i can store the data till the user comes to fifth screen.
    hope i'm clear with my clarification.
    Any help would be appreciated greatly.
    Thanks in advance.
    Anil.
  2. By saying that you cannot use sessions are you referring to both the servlet session object and say a ejb stateful session objects (If your using ejb)?

    If that's the case then your options are to persists the information client side through the use of hidden fields and javascript, which is a big pain. Or you could store the information in a table in your database used explicitly for the purpose of maintaining state information. Given the limitations of both of these options I would fight for the use of using session objects but that's just me.
  3. Yeah, this is a real pain about Servlets. You always end up junking up the session with stuff unrelated because the request just goes away.

    Stateful session beans: You have to be careful using these in a webapp across page loads, because at any time the user could leave your site, leaving your bean reference tied to the Servlet engine's session and you have to wait until the session dies before you can safely call remove(). You can run out of beans real quick (depending on the back-end server implementation).

    The other poster is right; you will probably have to use hidden fields to truley keep the stuff out of the session.

    But, you could use some disciplined programming and put it in the session without being too filthy. You could create your own "transaction scoped" objects as such:

    When hitting the first page, generate a transaction ID that is unique within the session. Any data you collect from that page is stored in a hashtable or other object in the session using that transaction ID as the session property. That key gets passed to subsequent pages and output as a hidden field. On these subsequent pages, when handling the request, just get the transaction ID, lookup your Hashtable (or whatever object it is), add the newly entered data, and continue. At the end, remove the transaction-scoped data from the session.

    The only issue, then, is if the user aborts in the middle, and you cannot detect it. Obviously, for session timeout, you don't have to worry, but there may be other places on the site where you can know that the user has aborted a transaction and clear out any transaction-scoped data. With creative naming of your session attributes, you should be able to manage this.

    I guess it's kindof a hack, but that's JSP and servlets (and web programming in general) for ya.

    Dave
  4. Why can't you use the session? It's simple, it works, it is what it is designed for. Use the session.
  5. It is not always desirable to store data that is not technically session-scoped in the session. Session scope is the scope for the user's entire visit to the site. What he is talking about that is data that is scoped during 4 or 5 requests, and is not relevant to any other part of the site.

    So, leaving non-session scoped data in the session can be anywhere from just messy to highly problematic. If you have a large site with many areas like this (sequences of forms), you have to make sure that your naming and code handles the cases when junky data is in the session. For example, if you have a field called "name" that is used in 3 different sequences, but has different meanings in each, you have to handle the case where that field is already in the session.

    Anyway, it's just cleaner to put only session-scoped data in the session.
  6. Can't agree Dave. Hidden fields result in larger, slower responses and can be a security risk.

    <So, leaving non-session scoped data in the session can be anywhere from just messy to highly problematic.>

    Just remove what you don't need


    <For example, if you have a field called "name" that is used in 3 different sequences, but has different meanings in each, you have to handle the case where that field is already in the session>

    Don't store Strings in the session. Store objects.
  7. A String is an Object, and it still seems messy to store stuff in session scope that isn't session scoped.

    It's the same reason you don't make all variables global, or why you don't make a global Hashtable that just holds all your variables in it. For the same reason a programming language has scopes to contain data and make it managable, Servlets have scopes as well. The problem in this case is that the scopes you have to choose from are limiting, and this particular case doesn't fit appropriately into any of the four scopes.

    You say "Just remove what you don't need", but as you may know, in a web application, it can be difficult if not impossible to determine when data is no longer needed. YOu cannot tell the difference between a user pausing, having left the site, or opened a new window to do something else. So, for data stored in the session, you typically have to leave it there until the session expires.
  8. "So, for data stored in the session, you typically have to leave it there until the session expires."

    If you can put it into hidden fields without impacting performance etc. then that is a good way to go.

    Otherwise use the session.

    There are no _better_ choices than that for the problem that you have described.

    Peace,

    Cameron Purdy
    Tangosol, Inc.