I've been looking at this for a while and now I am confused.  How do I avoid
declaring variables in my program?  Let's say I have a piece of code in
doPost that looks like this...

...
        else if ( request.getParameter( "step" ).equals( "step2" ) )
        {
            String code ;
            String duration ;
            VMRatesBean vmRates ;
            ClientListBean clientList ;

            synchronized( session )
            {
                code = (String)session.getValue( "code" );
                duration = (String)session.getValue( "duration" );

                code = request.getParameter( "code" );
                duration = request.getParameter( "duration" );
                session.putValue( "code" , code );
                session.putValue( "duration" , duration );

                vmRates = (VMRatesBean)session.getValue( "vmRates" );
                vmRates = new VMRatesBean( code );
                session.putValue( "vmRates" , vmRates );

                clientList = new ClientListBean();
                session.putValue( "clientList" , clientList );
            }

          // do stuff with code, duration, vmRates, etc.

Are you saying I shouldn't use these variables? Even if I put them in
another object chances are that I am going to want to move them to program
variables eventually anyway.  Take the above VMRatesBean object.  Let's say
I put that into some storage object and put the storage object in the
session.  Now, of course to use the storage object I have to get it OUT of
session.  Where am I going to put it but in a variable???

            Storage storage ;

            synchronized( session )
            {
                storage = session.getValue( "storage" );
            }

Didn't I just defeat the purpose of the exercise? The storage variable is an
instance variable, right?  So what's the difference?  But let's continue...
say I have my VMRatesBean object in my storage object in my session and I
want to print a list of elements from an ArrayList of VMRate objects.  Right
now I would code it like so...

            VMRatesBean vmRates ;
            synchronized( session )
            {
                vmRates = (VMRatesBean)session.getValue( "vmRates" );
            }

            ArrayList rates = vmRates.getAllRates();
            for ( int i = 0 ; i < rates.size() ; i++ )
            {
                VMRate rate = (VMRate)rates.get( i );
                out.println( rate.getDescription() );
            }

If I understand you, then neither vmRates or rates are OK variables.  Would
the option look something like this...

            Storage storage ;
            synchronized( session )
            {
                storage = session.getValue( "storage" );
            }

            ;
            for ( int i = 0 ;
              i < (ArrayList)( (VMRatesBean)storage.get( "vmRates"
).getAllRates() ).size() ;
              i++ )
            {
                out.println( (VMRate)( (ArrayList)(
(VMRatesBean)storage.get(
                      "vmRates" ).getAllRates() ).get( i )
).getDescription() );
            }

So I ask you, what variables are safe???  I'm either making this way too
complicated or it IS way to complicated.  Please tell me that I'm making
this way too complicated because I'm not even sure if the above statement
would work and I certainly don't want to maintain code like that!

Confused in VA,

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.