Nikolaos,
This is just a suggestion and might not be the best way...
Write a java class which would return a new number. (remember to
synchronize these methods). Thus if servlet1 calls IDGenerator.getNewID(),
it would return 1. When servlet2 calls it, it would return 2 and so on.
There would be a roll value as defined by you - 999999..(?) when you would
strt again from 1.
This would be a very crude method to define a user but nevertheless
workable in, my opinion. What do you think??
Raaj.
----- Original Message -----
From: Nikolaos Giannopoulos <[EMAIL PROTECTED]>
To: 'Rajendra Mishra' <[EMAIL PROTECTED]>
Cc: Servlet Interest Technology. <[EMAIL PROTECTED]>
Sent: Thursday, January 13, 2000 10:29 AM
Subject: RE: Is Global Session Possible?
> 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
