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
