thanks for the response--i figured i might have not been totally correct
responding to the original posting but i remembered reading something
similar while doing some other research and figured i would post that
information. in our own environment we are using Weblogic 3.1.5 as our HTTP
and EJB server and i believe it stores session data as a cookie (though i am
not sure if this cookie is kept in the browser memory or on disk)--on that
related note--do you have any experience with how session data is managed by
different web servers?
thanks for the response again--dipankar ghosh
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Craig
McClanahan
Sent: Thursday, April 08, 1999 3:33 AM
To: [EMAIL PROTECTED]
Subject: Re: CONNECTION object !!!
Dipankar Ghosh wrote:
> This may be due to the fact that you should only add objects that are
serializable to an HttpSession object. This URL may help:
>
> http://www.purpletech.com/java/servlet-faq/#11
>
> The FAQ here (which is referenced as an external documentation source at
the Sun Java site) recommends:
>
> "Specifically, a JDBC Connection object is not serializable, so should not
be added to the session. If you'd like to associate a connection with a
session, then store some arbitrary, unique handle in the session, then use
that to key off your own hashtable of connections. (Make sure to check to
make sure the returned connection is not null, and if it is, create a new
connection!)"
>
> Hope this helps...
>
> Dipankar G.
>
IMHO, the FAQ's recommendation to store only Serializable objects is a
little bit too simplistic to be a fundamental design pattern.
The reason for the recommendation (to store only Serializable objects) is
that some servlet engines, as a value added service, may copy your session
information to persistent storage and then reload it later. Typically, only
objects that are Serializable can be stored and reloaded.
So, your first option is to just use a servlet engine that does not offer
this feature (or lets you turn it off with a configuration variable) --
then, storing something like a JDBC Connection in your session is perfectly
reasonable.
Second, let's say you really did want to take advantage of servlet engine
support for storing and reloading sessions, but you still wanted a JDBC
connection stored there. One design approach to this includes the following
elements:
* Make sure that enough information to create (or recreate) the JDBC
connection is available in Serializable data objects in the session,
or accessible by some other means.
* Encapsulate your logic to extract the JDBC connection from the
session in a method that does this:
* Extract the connection object if it is there, and return it.
* If it was not there (i.e. this is the first request, or the
session just got reloaded), recreate the connection and
stash it in the session, and return it.
Third, another approach is similar to #2, but the object you store in the
session itself is a wrapper for the connection that is serializable, and
dynamically recreates the connection when needed, without the servlet code
that retrieves it from having to worry.
Using one of these approaches, there's no problem storing non-Serializalbe
objects in your session -- and this can be very useful!
Craig McClanahan
___________________________________________________________________________
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
