Excellent information.
Is RMI a reliable method for session persistence across the farm? seems
like it does have the potential to fail. I guess this possibility is quite
low, and somewhat acceptable for some deployments (or is it?).
I have implemented session managers for the Microsoft technologies, based
on a backend COM+ object and using a central database to persist the state
information. Generate, and use GUID's for representing the individual
connections on a per-session basis. this method eliminates the need for
cookies (no client dependencies), it has proven to be secure (short of the
ability of hijacking a session, but regardless of the technology you use
this will still be possible and very difficult to pull off). It has also
proven to be very scaleable. and when we consider a failure in any machine
in the system, this method is not effected. Oh yea...we were using
SqlServer (with active-active clustering) that way, there was really no
single point of failure. 100% reliable, 100% secure regardless of client
machine, and server environment.
Seems like its the same crap but a different pile.
Thanks.
At 12:03 PM 11/14/00 -0500, you wrote:
>I've tried to answer a few of these questions but one thing to keep in mind
>is that app. server vendors are likely to implement this in different ways.
>
> > I belive ive seen talk of a session object/layer. How does this
> > work? non-persistent cookie? does it rely on this cookie 100%.
> >
>The session is a server-side chunk of server memory that is dedicated a
>particular user's browser session. Typically it uses a non-persistant cookie
>to maintain a browser's identity. Some vendors rely 100% on the cookie.
>Others allow you to also use url rewriting that adds the "cookie" to each
>URL. This does mean you'll need to programmatically handle this in your
>code but its not that difficult.
>
> > what about scaleability concerns? can this scale on a web farm easily and
> > properly? (not redirecting user back to same machine in the farm - but
> > being able to handle the request transparently across your entire
> > farm). Basically, where is this session information stored? Server
>memory
> > where the session started, database or other shared storage medium on a
> > per-user basis?
>It uses server memory which means you don't want to store a few MBs of data
>per user. For instance, storing large java.sql.Resultsets in the session
>just so that the user can scroll through database records would be a bad
>idea if you plan to have a lot of simultaneous users. There is a timeout
>period that is set programmatically and/or by the server administrator to
>determine when this thing will die if the user doesn't return to the site.
>If you are using a server farm then this changes things a little. Again this
>is vendor dependant but from what I've seen once a particular user has been
>directed to a particular server in the cluster/farm then that user will
>continue to interact with that particular server until they are finished
>with the overall visit/transaction or until the server dies. Should the
>server fail then various app. server vendors have different ways of
>replication session information across the members of the cluster. In some
>cases they use RMI to push session information to a backup server so that
>when the user gets reconnected through the dispatcher/load balancer they'll
>be attached to the backup server. In some cases they use the database to
>persistent the session information so that each server knows to visit those
>database records to see if the user has a session preestablished.
>
>
> >
> > How are the sessions identified? some sort of GUID? How is this
> > generated, based on what criteria?
>
>I'm not sure if there is a standard on this but from what I've seen the
>cookie holds a GUID.
>
> >
> > What are the limitations of this? That is, if we start loading this up,
> > how bad will it be for server performance? Anyone do any specific load
> > testing?
>
>Many of the major Internet websites use these types of technologies so it
>seems that load can be handled.
>Keep in mind that JSP is really just a Servlet and servlets can power very
>big websites easily.
>
>
>Burr
>[EMAIL PROTECTED]
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Robert Chartier
Author, AspFree.com
604-975-5590
[EMAIL PROTECTED]
http://www.aspfree.com/devlinks
htp://www.aspfree.com/authors/robert
http://www.aspalliance.com/nothingmn
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
