On Wed, 1 Sep 1999, Mike Engelhart wrote:
> So the big question is, "Is the session ID a valid unique identifier for my
> database table"? I plan on removing the row from the database immediately
> after getting the object back into a session on Server A as well as having a
> trigger run that will make sure that any entries that are longer than 30
> minutes old be removed, but I don't want the possibility of two different
> users reading the same session object from the database at the same time
> because they have the same session ID. Mixing up people's credit cards
> would not be a good thing....
I would recommend against doing this. I did exactly what you describe on
a past project, and ran into a few things:
1) Servlet implementations regenerate session IDs after restart
if you have a problem and restart your servlet engine, most servlet
engines will ignore existing session IDs passed in by browsers, and
attempt to set new ones. I guess the engine can't find a session in
RAM for that ID, and decides that ID is no longer valid
2) Servlet engines that support clustering create different IDs between
nodes in the cluster
in Apache JServ 1.0 and WebLogic 4.5, the session ID has the host/port
of the servlet engine that created the session packed inside it. This
information is used to ensure session affinity (so the browser always
gets routed to the same machine that the session was created on).
However, if you restart a node in the cluster, and the machine is
routed to a backup host, I'm fairly certain that rule #1 above will
kick in, and the browser will get reassigned a new session ID.
Instead of session ID, I would suggest setting your own session ID to key
data in the database off of. You could grab the session ID generation
code from Apache JServ for an example (it's pretty extreme). or you could
roll your own doing time off the clock + synchronized counter + last octet
of server's IP address or something.
> Another thought that crossed my mind would be to create a third column that
> put the IP address of the client into the database as well to add a little
> more insurance to the scenario.
This is a little messy because of DHCP and proxies. I've seen client's IP
address change in the middle of a session do to a proxy getting
renumbered. It's a pretty uncommon occurance, but enough to make me not
want to.
good luck
-- James
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
