× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.