Hi! >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).
So can you explain how to do such a periodic "is session open" request? Q Beukes 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] > > > -- View this message in context: http://www.nabble.com/Session-handling-in-HttpClient-tp18106268p20343451.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
