"Christopher K. St. John" wrote:
> "Craig R. McClanahan" wrote:
> >
> > "Whaley, Dave (HQP)" wrote:
> >
> > > The most convenient way to do this is to store the
> > > objects in the session until we are ready to write them to the database.
> > > The app server is Weblogic 5.1. Are there any technical limitations
> > > we will run into?
> >
> > Think of a session as a glorified Hashtable. ... There is nothing
> > magic going on.
> >
>
> But there's magic as soon as the the web app is distributable,
> no?
Well, there's some magic inside the container, but not really any in the session
:-).
The key reason for this is a requirement in the servlet spec -- at any given
point in time, all requests accessing a particular session must be served by one
and only one JVM. It is legal for the container to migrate a session from one
server to another (for load balancing or failover purposes), but only "between"
requests.
>From the servlet programmer's perspective, that means you can count on an
attribute you stored with session.setAttribute() being immediately visible to a
simultaneous request for the same session calling session.getAttribute(). Such
simultaneous requests happen more often than you would think, in scenarios like
this:
* Framed presentations (the browser will typically send up to
four simultaneous requests for the various frames)
* Dynamically generated images (<img> tags generate simultaneous
requests too
* User starts a request, presses STOP, and starts another request.
> I suppose it's fair enough that the design of a distributable
> app needs to be different from a non-distributable app. You can't
> (always) just set the "distributable" flag and expect things to
> work. I've seen info (stealing heavily from advanced-servlets here :-)
> along the lines of:
>
> - 2-3k worth of session data to limit traffic
> - Keep pointers to objects in distributed store, not the
> objects themselves
> - Just use your RDBMS
> - Use vendor-specific solutions
> - Just pin the user to a server
> - Etc.
>
> Is this all too container-specific, or are there some general
> guidelines about what sorts of problems you can run into?
>
The details here depend very much on how the particular container you will be
running on supports distributed apps. What works really well on one platform
might be dog slow on another -- the best people to ask would be your platform
vendor, because they have likely optimized their server for particular design
patterns.
That being said, in most environments you will generally do well to minimize the
amount of data you store in the HttpSession, and (in particular) remove it from
the session as soon as you do not need it any longer. However, there is no
silver bullet -- if you need state information maintained across multiple
requests for the same user session, you have to store it *somewhere*. It's a
matter of finding the best option for your application, running on your server
hardware, with your selected servlet container.
>
> -cks
>
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
