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
