Hi Russ, >No, sorry if I was being vague.
No problem. >I don't want Struts to create a session simply by accessing an action; I want >to control > the number of sessions being handed out. I don't believe that this is possible. The session creation happens at the servlet container level(in your case Weblogic); and sessions(if they dont exist), implicitly for each request. >A session is created by virtue of them just getting to the login page. Yes, this is true. >Weblogic is telling me that there are active sessions, even though I >have invalidated the session once the user logs out. So I don't know if >a person is still logged in, or if it is those extra sessions that are >being handed out by Struts. It sounds like you need to implement the concept of "LoginSession", to count the number of users that are logged in. -----Original Message----- From: Baker, Russ A [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 12:10 PM To: Struts Users Mailing List Subject: RE: Re: Session problem No, sorry if I was being vague. I don't want Struts to create a session simply by accessing an action; I want to control the number of sessions being handed out. All of my pages are using Tiles, so to call for instance the login page, which doesn't create a session; I have to call an action so that the page is rendered using the Tiles framework. A session is created by virtue of them just getting to the login page. If the user logs in successfully to the system they now have 2 sessions instead the desired result having only one that is assigned to them when they successful login. That is a waste of memory! So what I was getting at with the "I don't want to piss off the users by shutting down the system while they are still on it..." was that Weblogic is telling me that there are active sessions, even though I have invalidated the session once the user logs out. So I don't know if a person is still logged in, or if it is those extra sessions that are being handed out by Struts. Capiche? -----Original Message----- From: James Harig [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 9:53 AM To: Struts Users Mailing List Subject: RE: Re: Session problem 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/HttpSer vletRequest.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] --------------------------------------------------------------------- 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]
