Hi, there
It happens that I'm having this same design problem today :-) (pretty interesting how things matched, huh?!)
I totally agree with Wiebe here - his is the only reasonable work-around that i could imagine to this problem. I also thought about serializing the Handle, but i think it won't work because the stateful session with the SFSB could time-out while the web server restarts and until it will get called again.
So I cannot see another way, other than persisting the HttpSession data until the same user logs-in again. But, maybe, someone else has another, even more interesting solution...
Radu
Wiebe de Jong wrote:
The simple answer is to store all your session data in a database, with a
cookie value as the key.
When the client connects, get the cookie value, read the session data from the database, do your stuff, update the database, and respond to the user.
This will create a permanent session, which will survive shutting down the browser, web server, app server, and whatever else. The session will only end when the user explicitly logs out and terminates the session.
If you don't like the performance hit of going to the database every time, then add a plugin. When the application starts, the plugin will read all the sessions from the database into memory. When the application ends, the plugin would write out all the sessions to the database.
Wiebe de Jong
-----Original Message-----
From: Chaikin, Yaakov Y. [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 12:37 PM
To: 'Struts Users Mailing List'
Subject: [Very OT] Hypothetical challege
Hi,
This is a hypothetical question, but it's interesting to me if anyone can come up with a solution and what that solution would be.
A few facts and requirements:
1) Suppose you have 2 machines. One must serve as your web server and the other must serve as your EJB server. 2) Suppose you must keep track of some sort of session data for each client. How you store the session data is flexible to a point... You want to take advantage of stateful sessions for whatever reason (maybe your EJB server has more resources or something like that). 3) You obviously have a remote reference to your stateful session EJBObject in your web tier. 4) For whatever reason, you anticipate that you will want to restart your web server now and then while there will be some moderate traffic to it going on. Yet, you don't want to make all the clients lose their state. 5) You can use a cookie if you want to remember which client was which when the server restarts. 6) You have the option of storing the remote references to you stateful session EJBObject by getting EJBObject.getHandle() and storing it on the web server machine in a serialized form. 7) No, you can not buy another web server and cluster them! Let's say there is no more money left.
How do you catch "server/web app shutdown" event with no non-portable code, so you can go through all your sessions and save the remote references to your stateful beans on the EJB tier on hard disk so when the server starts back up you would be able to restart the entire app without making the clients lose their state?
Yes, this way of a contrived situation, but I am just very interested in how this could be accomplished.
Anyone?
Thanks, Yaakov.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
