Raaj,
I'm not sure that this would work since each call to the servlet would
result in a new ID. I need to have something such that 1 or more calls
from a specific user (from 1 or more browser sessions OR spawned windows)
results in a SINGLE NEW ID (that is shared).
Any thoughts....
--Nikolaos
On Thursday, January 13, 2000 8:55 PM, Rajendra Mishra
[SMTP:[EMAIL PROTECTED]] wrote:
> 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
