Hans Bergsten wrote:
> Craig McClanahan wrote:
> > > [...]
> > 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.
>
If the scenario you describe (keeping a database transaction alive across multiple
servlet requests) is what you're doing, I agree that notifying the user is the best
thing to do. However, that approach would seem to cause scalability problems because
server side resources are occupied on "human" time scales (i.e. between requests).
I tend to accumulate transactional "state" information in session variables (in
somewhat the same spirit as a stateful session bean in EJB environments), and execute
database-related transactions within the scope of a single request -- in which case,
re-establishing the connection transparently can be useful. Of course, in the
particular case of database connections, it can also be useful to share a connection
pool between multiple sessions, rather than establishing a connection per user. But
the principle of being able to transparently re-create session variables that are not
themselves serializable can be quite helpful.
>
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
>
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
