Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Large Web Form Losing Session Data

 
Chris Snapp
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13055
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Chris Snapp
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13055
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic