Hi Quitin, Thanks for the response.
That does help me understand clearly about sessions. I will try to implement the same and incase of any questions, will get back to you. Thanks again for your time. Regards, Jade On Wed, Jun 25, 2008 at 12:47 PM, Quintin Beukes <[EMAIL PROTECTED]> wrote: > Well, sessions are server related. Let me give you an idea of how sessions > work: > > In this example I will use "SESSID" as the cookie name, but this can > be configured, and differs in all implementations. > > First Request > 1. Client visits server for the first time. > 2. Server checks if the "SESSID" is set, it is NOT, so it creates a > new session and generates a session ID to identify this session. > 3. Server sends a "Cookie" header so teh client will create the cookie. > 4. Client saves cookie for given domain. > > Second request > 1. Client sends request a second time > 2. Client also sends all cookies it now has, in this case SESSID which > contains a string session id. > 3. Server checks to see if SESSID was sent. > 4. It was, so server takes this session id it received in the cookie, > and sees if it has a session by that identification > 5. Server locates the session data, and loads it into instance > variables for the script/jsp/servlet/whatever. > > This is basically what happens. A session is nothing more than a way > for the server to identify that the same client is visiting. This is > done with cookies 99% of the time, and sometimes with GET variables > (but same story, just a variable sent with every request containing > the session id). > > Sessions are 100% server side. The client does nothing more than carry > a unique identifier, and all session variables/data is stored in a > persistent state on the server. There is no special communication or > nothing. It's nothing special. > > You can create your own session implementation by simple having an > array of open sessions, and each array items is a Map<String, String> > of variable:value pairs. Then send cookies to track the clients, to > know which Map to use. Simple. > > So the solution to your problems are this: > You can support the session by receiving/resending cookies on all requests. > > You can do timeouts ONLY by knowing what timeout is configured on the > server and having a timer track this yourself. So if the server > session timeout is 1 hour, then have a time that checks the period of > inactivity for requests, when it exceeds 1 hour, kill the session on > your side by deleting the cookie and doing any > cleanup/reinitialization. > > Alternatively, to generically support all servers, you might want to > do a periodic "is session open" request, which is basically a request > to the server that checks if the session is open. If you want to do > this, there is a very safe way to implement something like this. Just > ask me and I'll explain it (it's not as simple as checking for the > presense of a session, as this will always return true). > > Q > > On 6/25/08, Wierd Programmer <[EMAIL PROTECTED]> wrote: > > Hi folks, > > > > I am planning to use HttpClient in the client end of a Swing based > client - > > server(Jboss) application. > > > > I am wondering how to handle sessions and specially session time out > > situations...Are there any listener kind of things for session? Incase > If I > > would like to show a message to the user saying session will time out in > so > > and so seconds/minutes how do I do it? > > > > Please let me know how to go forward with this. > > > > Regards, > > Jade > > > > > -- > Quintin Beukes > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
