Craig McClanahan wrote:
> 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.
Yes, I agree. That's a more scalable approach that probably works for most
scenarios.
> 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.
Yes, definitely.
--
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
