aspose file tools*
The moose likes Java in General and the fly likes Large Web Form Losing Session Data Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Large Web Form Losing Session Data" Watch "Large Web Form Losing Session Data" New topic
Author

Large Web Form Losing Session Data

Chris Snapp
Greenhorn

Joined: Nov 14, 2003
Posts: 16
Hi, I've been having problems with my web application where I have a large multi-paged form that the users need to fill out. Currently this form's fields are populating a POJO object sitting in the session scope. As you navigate between tabs the form on the page is submitted and a homegrown "beanfiller" takes the parameters being passed up and populates the POJO.

In any case the issue is that this app is hosted on a farm of Tomcat servers where the session timeout is set to 30 minutes. So if someone were to start filling out a form and then take a phone call, when they returned and clicked on another tab the previous data would be gone since the POJO object had been dumped.

I'm not sure how to handle session timeouts without persisting the form page data to the database on each tab change. Any help would be appreciated. Hopefully I explained the problem correctly. I don't have a lot of experience with forums.

Thanks
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12782
    
    5
If this was my problem I would set a long-lived Cookie with a unique identifier on the user's browser and serialize the POJO out to disk with a file name equal to the unique identifier after every form has been processed. I do this sort of thing with on-line exam simulator where the user may get dropped during the exam.
Serialization is surprisingly fast if your POJO does not refer to big objects shared with other users.
Bill
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
You could also move your storage from memory to database or even flat files. There's a fair performance hit, but unless you're stressing the system your users might not notice too much.

A session-like solution might be to move the data to a hashmap in memory. I'm not sure how you'd ever know when it's time to remove things. The user could just walk away and use up memory forever.

Note that the session or other in-memory solutions will not hold up in a clustered environment where a user may or may not hit the same server every time. Just in case that's in your future.

Here are some notes I made about Internet Architectures a few years ago. You can store data like this ...

and many more clever places, I'm sure!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Chris Snapp
Greenhorn

Joined: Nov 14, 2003
Posts: 16
Wow....I was completely prepared for a response along the lines of "Holy Heck you need to just stop what you're doing and do it this way!...".

<William Brogden> I'll have to read up on serialization of objects because to be totally honest I really don't have a clue how that works. Pretty sad, I know. But setting a cookie that exists while the person is working on the form is a pretty good idea. Hopefully if I can figure out the other part I can confidently say its a great idea.

<Stan James> In response to the in-memory solutions....that is actually what the issue is right now. I am currently working against a farm that has not only a Tomcat session timeout but a load-balancer timeout period.
As for saving to the database, I had thought of doing this awhile back and it was only going to be able to be done two ways the way I see it.

1. Dupe the entire table structure of the form to be used as a temporary holding area. (Horribly nasty in my mind, especially since I have multiple large forms with the same issue)

2. Allow the user to work directly off of the final version of the form. This becomes an issue when they are allowed to go back and edit it since they would be saving their changes as they go. That might confuse someone and also there would be no way for them to hit a cancel button and not have the changes take effect.

Please feel free to let me know if this is only an issue because I am not following some strict standard or something. Another reason for my posting to a forum is to find out if I am going down a horrible path. I have never worked with EJB's and I have minimized my use of strict servlets by using JSP to pass objects to session POJO objects handling DB transactions through Hibernate.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Another option is to use a combination of frames and autorefresh.

For example, put the form into the top part of the frame, and have a small additional page at the bottom, for example containing a copyright notice or something. Have that second page reload itself, say, every 60 seconds.

That way the tomcat session will not timeout as long as the user has the browser window open, no matter how long it takes him to fill out the form.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12782
    
    5
Dupe the entire table structure of the form to be used as a temporary holding area. (Horribly nasty in my mind, especially since I have multiple large forms with the same issue)

If you think of the form data in terms of a Java Collection, maybe this is not such a bad approach. You could have a Map where the keys are the same as the form variable names and the values are Strings or other serializable Java objects.
-- In terms of convenient representation of forms in an editable fashion that avoids lots of form specific coding, consider using XML with a generalized HTML form generator.
Bill
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
My current app writes work in progress to the databse of record with a status indicator on the root of the graph to show that it is still in progress. That makes it invisible to other processing, and we can sweep stale graphs out of the system every night. I also did one app with a temp database that just stored blobs ... serialize whatever object graph you need to a big string and store it, just like the cookie idea.

Cookies are somewhat insecure. A smart hacker can read or modify them or make new ones from scratch. Serialized data would be interesting there ... harder to hack but not impossible. You wouldn't want to validate somebody's MasterCard and then give him the chance to make up a new number before you save it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Large Web Form Losing Session Data