> This is not a good practice. Contents of sessions should be
> serializable, and connections are not. Imagine a distributed servlet/jsp
> cluster!
While i agree that stuffing java.sql.Connections into a session isn't a good
idea, where does it say that contents of session should be serializable?
That's one approach that people are using, but after writing code to do this
myself, I don't think that it's necessarily the best architecture. I'm
finishing up adding code to my web application to serialize data from a
secure form where the object is put into a database and then pulled back out
when the user returns to the non-secure server and it's a less than ideal
way of handling it. I am betting that the overhead of doing this is
non-trivial if you have a lot of users. I'm really hoping the 2.2 API (i
haven't had time to read it very carefully) will allow distributed servlets
at least to a degree where you can set security permissions or some
mechanism to allow passing state information from one JVM to another (even
if this means i have to write my own RMI code to do it). I just don't
like having to write objects to a database as a temporary measure just to
maintain state. I don't know about anyone else but that seems archaic to me
when there's powerful networking tools available like RMI (replace CORBA
here if that's your thing).
Just my 2 cents
Mike
===========================================================================
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
