Raaj,
Once again your reply is really interesting and has definately crossed my mind.
The MAJOR issue I have however (with any solution - mind you) is in concocting the ID
that would uniquely identify a given user....
Any ideas
On Thursday, January 13, 2000 8:19 PM, Rajendra Mishra
[SMTP:[EMAIL PROTECTED]] wrote:
> Nikolaos,
> If you are saying that you need to share the same session irrespective
> of the browser, then things might get a bit convoluted. I would suggest that
> you store the users, which would be identifiable via some mechanism, in
> memory. Whenever you get a request, you would check into this hashtable(?)
> if the user is already registered. If not, then you need to create a new
> session else continue. The problem woud be when to delete this user.
> There would have be a combination of events to do this which still might
> not be the fool-proof. In the unload event of ur page, you can call a
> servlet whose sole purpose would be to delete the user from the hashtable.
> If you know the maximum time between and concurrent request, then you can
> log the last accessed time of the user in the user-object. If a request
> comes in which is more than that time-span, then you can conclude that the
> session was lost in an abnormal manner because the user is still there and
> the max time for the session has expired. You could have used the
> HTTPSessionListner but in your case, it probably wouldn't work. Another
> thing that you might want to read up on is Servletcontext. See if this would
> provide some session help across multiple browsers.
> Hope this helps...
> Raaj
>
> ----- Original Message -----
> From: Nikolaos Giannopoulos <[EMAIL PROTECTED]>
> To: 'Rajendra Mishra' <[EMAIL PROTECTED]>
> Cc: Servlet Interest Technology. <[EMAIL PROTECTED]>
> Sent: Thursday, January 13, 2000 9:58 AM
> Subject: RE: Is Global Session Possible?
>
>
> > Raaj,
> >
> > Thanks for the reply. See comments below:
> >
> >
> > On Thursday, January 13, 2000 7:21 PM, Rajendra Mishra
> > [SMTP:[EMAIL PROTECTED]] wrote:
> > > Hi Nikolaos,
> > > If you cannot use user-names and password, i think th best way would
> > be
> > > to pass a cookie with some unique charecteristic of the session. Then in
> > > your servlet code, you can check if the cookie has been writen or not
> and
> > > determine if it is in the same session. You will have to remember to
> > delete
> > > the cookie once the session is over.
> > > Or, simply check on getSession(true).isNew(). It would return a
> > boolean
> > > value indicating the session status.
> >
> > Great. This was my last thought on what I would do if I decided to use
> > cookies, however there are some problems:
> >
> > (1) I need this to work accross multiple browsers i.e. I need multiple
> > browsers invocations (i.e. IE, NN, etc...) to correspond to a single
> > session. Cookies are stored locally PER browser and thus other browser
> > invocations will result in new sessions. If cookies were available system
> > wide then this could work BUT they are not.
> >
> > (2) When is the cookie deleted? There really is no clear cleanup point in
> > our application - the application continually provides feedback with no
> > single page which can be denoted as the last page. Moreover closing a
> > browser doesn't provide any real signal that can be used to do cleanup
> > (except the unload event BUT this might not have a chance to complete its
> > operation if it even gets called at all). That being the case, I
> > considered that, the expiration of the cookie could be set such that it
> > expires within a certain period of time. Two problems that I can think
> of:
> >
> > (a) if the expiration is set too long (e.g. 30 minutes) then a user who
> > starts a session, then exits his/her browser and starts a session again
> > would not be able to start a new session for at least 30 minutes.
> >
> > (b) if the expiration is set too short (i.e. 30 seconds) then the system
> > will spend a lot of time trying to write cookies and we expect to have our
> > application provide feedback every 3 seconds or so which may unnecessarily
> > provide too much load - especially if the number of users are high (we may
> > have anywhere areound 100 to 10000 users at peak time).
> >
> > All this of course is my opinion and I may be wrong. Any comments....
> >
> > > As for point -2, there would not be any need to invalidate the old
> > > session if a new session is created as a new session itself would not be
> > > created if there is any session already existing.(whew!)
> >
> > Point 2 is provided as an option to not having an answer for Point 1.
> > Point 2 could very well be possible as I have not necessarily come up
> with
> > a way to get a unique user identifier (yet).
> >
> > --Nikolaos
> >
> >
> > >
> > > Hope this helps...
> > > Raaj.
> > >
> > > ----- Original Message -----
> > > From: Nikolaos Giannopoulos <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, January 12, 2000 8:33 PM
> > > Subject: Is Global Session Possible?
> > >
> > >
> > > > Hi,
> > > >
> > > > Is it possible to do either of the following:
> > > >
> > > >
> > > > (1) Be able to uniquely identify a surfer such that ALL requests
> > (whether
> > > > from current browser, spawned browser(s), or other launched
> browser(s))
> > > use
> > > > the SAME session.
> > > >
> > > > OR
> > > >
> > > > (2) As soon as a "new session" is created INVALIDATE ALL other
> sessions
> > > for
> > > > a given surfer for reuests whether the session(s) were created from
> the
> > > > current browser, spawned browser, or other launched browser(s).
> > > >
> > > >
> > > > We have the need for providing a mechanism such that the last access
> to
> > A
> > > > page, by the user from any browser or spawned window, is the ONLY
> VALID
> > > > session.
> > > >
> > > > DOES ANYONE HAVE ANY CREATIVE IDEAS on solving this....
> > > >
> > > > Any help is appreciated...
> > > >
> > > > --Nikolaos
> > > >
> > > >
> > > > P.S. We can NOT use user names and passwords even if we wanted.
> > > >
> > > >
> _______________________________________________________________________
> > > > Nikolaos Giannopoulos
> > > > Director, Solmar Solutions Inc.
> > > > [EMAIL PROTECTED]
> > > > www.solmar.ca
> > > > (819) 684 - 0023
> > > >
> > > >
> > >
> >
> ___________________________________________________________________________
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > > body
> > > > of the message "signoff SERVLET-INTEREST".
> > > >
> > > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > > Resources:
> http://java.sun.com/products/servlet/external-resources.html
> > > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> > > >
> >
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
