Hi, Here's my take on the subject....
The key here is that you want the users to finish what they are doing before you let the server shut down. This means a few things: 1. If the webapp uses the concept of logging in, new "login sessions" shouldn't be allowed. Attempts to login should be responded to with some sort of error: "The server is being shutdown..." 2. Existing sessions should be invalidated as soon as their next request has been submitted, and the response should be redirected to an error message "The server is being shutdown". For example, the when user clicks: "check mail", a request is generated to the server(which calls a Struts action); respond to this request by invalidating the session, and redirecting to an error page. 2.a. There is an exception to this case: What if the user is in the middle of a multi-step process. For example step 2 of the shopping cart checkout process. In this case, you would want to postpone calling session.invalidate() until after the checkout transaction is complete. We will call these "multi-step transactions". To facilitate these items, you will need some method of informing your webapplication that the server is going to be shutdown. One way to do this would be to set a flag in the application context; another way is to create a lock file; yet another way is to set a flag in a database. Once the webapp has been informed that the server is going to be shutdown, wait until all the user sessions have been invalidated, and shut it down. I have thought about this subject on a number of occasions, but have never implemented it. I would be glad to hear of any feedback. Thanks, James -----Original Message----- From: Ed Griebel [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 10:09 AM To: Struts Users Mailing List Subject: Re: Re: Session problem The key is to not put anything in your session. Actions are the obvious place to look for things being stuffed into the session (via request.getSession().get/setAttribute()), but you might have a filter that creates a session as part of what it does, or an action that has a session-scoped form in struts-config.xml. If you want to only test for the existance of a session in your action, don't forget to call request.getSession(false) and then check the return for null. See the javadoc: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html#getSession(boolean) Also, if you have other webapps on the web server, they might be using sessions in their webapps, so anything you do in yours will be for naught. -ed On 12/6/05, Baker, Russ A <[EMAIL PROTECTED]> wrote: > It is Weblogic. I am using a "graceful" shutdown so that if people still > have open sessions, they can complete what they are doing. The other > alternative is to force shutdown, but I am afraid I will make enemies if > I do that... > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Laurie Harper > Sent: Tuesday, December 06, 2005 3:53 PM > To: user@struts.apache.org > Subject: Re: Session problem > > Baker, Russ A wrote: > > Hello, > > > > I am trying to figure out how to stop Struts from creating a session. > > What seems to happen is that once I call an action, a session is > > created. This is a problem because when I want to gracefully shut down > > my server, it complains that I still have an active session. Is there > a > > way to configure Struts so that it does not create a session when an > > action is called? > > A session is created the first time something accesses it. Since Struts > stores various things in session scope, I don't think you can avoid > having one created. > > What container are you using? It seems like an odd behaviour to refuse > to shut down if there are any active sessions... Are you sure it's > referring to an HTTP session (as opposed, for example, to a Hibernate > session or something)? > > L. > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
