RE: [Very OT] Hypothetical challege
Wow! And I really was just making this up... Although you have a valid point about the session timing out, it's not 100% in context. Here is what I mean... Sessions time out because it is assumed after a certain amount of time that the client will not come back. Persisting your temp session data to the database kind of jumps over that business rule and says that clients can come back after ANY time passes. If that's what you wanted to begin with - fine. But all you are trying to do is prevent a server restart from destroying a user's session, then sticking it into the database is really a strange thing to do, i.e., you are changing the original behavior just to satisfy this requirement... The point is to in fact let the client lose the session after the same amount of time he would have lost it in the first place. (Not sure if there is an equivalent in EJBs to servlets' setSessionTimeout(), but I would assume that there is.) So, all you should really do (taking original business logic into account) is increase your session time out by the amount of time it takes to restart. Preferably you should do it as your web app ends so it will still have the default session time out the rest of the time. You could easily do this in contextDestroyed() in (ServletContextListener) and reset it back in contextInitialized(). So, now the only question that remain is how do you capture every session handle that's out there serialize it for later use... Well, how about keeping a HashMap in ServletContext scope with a key that would match the session cookie and the remote handle as the object? In ServletContextListener.contextDestroyed() serialize the entire HashMap with the handles. In ServletContextListener.contextInitialized(), deserialize the HashMap with the handles. Now, when the client comes in, check if he has sessionID cookie and see if it's in your HashMap. You know the rest... One caveat would be that you would have to build something to make the HashMap expire session keys and their values once the session gets destroyed. Hmm... but how would you do that??? There might not be a solution that would make it virtually invisible that the sever got restarted... Partially, I am still unclear how the servlet's session ID get propagated to the EJB session ID. Are they the same? I don't know... More research is needed. Of course, all this is very theoretical and I was only originally asking to drill down to the lowest level of this and understand what's possible. Even if this were possible, I would still go with persisting the session ID in the database... Otherwise, this is starting to look too much like a hack instead of an elegant solution, which is what I was after in the first place. Yaakov. -Original Message- From: Radu Badita [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 4:42 PM To: Struts Users Mailing List Subject: Re: [Very OT] Hypothetical challege 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
Re: [Very OT] Hypothetical challege
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]
RE: [Very OT] Hypothetical challege
Yes, persisting the session data in a database is the obvious answer. No question that I agree with that. However, I was trying to find a solution that would get a bit "EJB-happy". I guess, I am not really sure myself what I am asking... I was just trying to stretch the use of Stateful EJBs and its handle, but the question didn't come out right... Never mind. Sorry for wasting your time and thanks for your replies anyway. Thanks, Yaakov. -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 5:48 PM To: Struts Users Mailing List Subject: Re: [Very OT] Hypothetical challege On Wed, 26 Jan 2005 14:40:11 -0800, Wiebe de Jong <[EMAIL PROTECTED]> wrote: > > 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. Or, use JMS to write the changes, so they happen asynchronously. - 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]
Re: [Very OT] Hypothetical challege
On Wed, 26 Jan 2005 14:40:11 -0800, Wiebe de Jong <[EMAIL PROTECTED]> wrote: > > 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. Or, use JMS to write the changes, so they happen asynchronously. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Very OT] Hypothetical challege
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]
[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]
