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
