Craig McClanahan wrote:
> > [...]
> IMHO, the FAQ's recommendation to store only Serializable objects is a little
> bit too simplistic to be a fundamental design pattern.
I agree, but I have a comment about your second and third suggestions below.
> 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.
This works fine.
> 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.
If the reason for storing the connection in the session in the first place
is to let multiple requests be part of the same database transaction, these
last two approaches can cause problems. I believe that's a common reason but
it doesn't work well at all if you just reestablish the connection.
In this case it's better to let the servlet realize that the connection is
gone and inform the user.
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
___________________________________________________________________________
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
