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.
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
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
Joined: Nov 14, 2003
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.
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
Author and all-around good cowpoke
Joined: Mar 22, 2000
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
Joined: Jan 29, 2003
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.