RE: What happened to rpgenerationx.com? -- WEB400

Joe,

Thank you for posting this as I think it is going to save me a ton of heart
ache in the next couple of weeks.  I am getting ready to implement a Servlet
based shopping cart (in conjunction with our CGI website) and this is the
first I've heard of any problem with Servlet variables, but I would rather
hear about it now than after I go live!

I already rely heavily on HttpSession, placing numerous objects in the
session and pulling them into variables. In your storage class, do you
create individual variables with their own getter and setter mehods for each
variable you want to track or do you use something like a HashMap with
simple get() and set() wrappers?  It would seem that the HasMap approach is
more scalable but I don't know if there are more concerns with that approach
that I should be aware of, maybe performance wise?

Thanks,

Joel R. Cochran
Director of Internet Services
VamaNet.com
(800)480-8810
mailto:webmaster@vamanet.com


> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Tuesday, July 30, 2002 7:30 PM
> To: web400@midrange.com
> Subject: RE: [WEB400] What happened to rpgenerationx.com?
>
>
> > From: Nathan M. Andelin
> >
> > I've heard that Websphere manages a number of components in
> addition to
> > Servlets.  The session object may be a good example.  Do
> > programmers need to
> > synchronize calls to session methods, for example.  Or are
> a number of
> > things like that automatically synchronized?
>
> Synchronization is not required in order to be threadsafe,
> provided you
> access only threadsafe variables.  Instance variables in your
> servlet class
> are not threadsafe, since there is only one copy of the
> variable shared
> among all the threads executing that servlet.  On the other
> hand, variables
> passed on the stack (e.g., as parameters to methods) are stored on the
> stack, not in the instance, so are threadsafe.
>
> This being the case, when a servlet method (as I said,
> usually doGet or
> doPost) is invoked, it is passed two thread-specific variables, the
> HttpServletRequest and HttpServletResponse.  Invoking the
> getSession method
> of your thread-specific HttpServletRequest object gives you a
> thread-specific (and thus threadsafe) HttpSession object.
>
> By attaching your own working storage class to the
> HttpSession object, and
> accessing only variables contained within that object, you are now
> threadsafe, without the penalty of synchronization.  This is
> sort of a rule
> of thumb for any type of multi-threaded programming - store
> it on the stack
> (or on the heap).
>
> So, the upshot of this whole thing is that servlets should
> avoid instance
> variables.  If you must have one (perhaps for inter-session
> communication),
> access to it must be synchronized.  But in general you can avoid
> synchronization by using threadsafe variables stored in the
> session object.
>
> Joe
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> or email: WEB400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>