Yes, that would make sense.
With regard to the session variable, I found this in a FAQ at jguru which I
beleive applies:
"With respective to multithreading, beans that are created with a request or
page scope are new instances for each JSP call so these beans need not be
thread safe. Beans that are created with a session or application scope must
be thread safe as multiple pages could be accessing the same bean at once.
In either case, if beans are accessing shared resources (like pooling
connections behind the scene), you must make sure this sharing is
thread-safe"
Although this is with reference to JSP's I'm assuming that a bean with
session scope would be the same as a servlet-supporting class stored in the
servlet's session object.
As far as I can see this is to handle a situation where a user has multiple
browsers open on the same machine accessing
the same servlet, and this is the reason you would need to synchronize
access to it.
Perhaps an unlikely situation to arise but one which should be covered
anyway.
I found this in "core servlets and jsp's" by Marty Hall:
"Since each user has a separate session, it is unlikely that multiple
threads will be accessing the same shopping cart simultaneously. However, if
you were paranoid, you could conceive of a few circumstances where
concurrent access could occurr, such as when a single user has multiple
browser windows open and sends updates from
more than one very close together in time."
The long and short of this being, you do need to synchronize shared methods
or variables with session scope,
so you were right the first time : )
Thanks,
Paul
> -----Original Message-----
> From: Bo Xu [mailto:[EMAIL PROTECTED]]
> Sent: 16 July 2001 19:14
> To: [EMAIL PROTECTED]
> Subject: Re: concurrent access to variables with class or block scope
>
>
> Paul Foxton wrote:
>
> > Hi Bo, thanks for your reply
> >
> > I think I follow you, and you seem to be saying the same
> things as Hans,
> >
> > apart from this part:
> >
> > > no, but please notice that this local/method can not
> refrence to a
> > > instance/static
> > > field of MyServlet, or refrence to a object shared by several
> > > Threads, for
> > > example:
> > > doGet(...){
> > > ...
> > > HttpSession session=req.getSession();
> > > session.getAttibute(...)/setAttibute(...);
> > > ...
> > > }
> > >
> > > session is a local variable, but because it references to
> > > req.getSession(), so
> > > I think "synchronized" need to be used here
> > >
> >
> > - isn't the point of the getSession method is that a new
> instance of the
> > Session object is created for each new request, so each new
> thread spawned
> > by a request would have its own instance of Session?
> >
> > Hope I havn't misunderstood you.
> >
> > thanks,
> >
> > Paul
> > [...]
>
> Hello Paul, I find it is not suitable to use HttpSession as
> the sample for
> Thread/local-variable issue in my last email, it make the
> explaination more
> complicated :-) because I found(with TC4.0b5), for every req,
> session.hashCode()
> is different, even if session.getId() is same.
>
> I still guess session.getAttibute(...)/setAttibute(...) need to be
> "synchronized",
> but perhaps I can not use session itself to do it, I think it
> is possible to
> use a
> context-wide object as "mutex".
>
> so I think I need to use another sample:
>
> doGet(...){
> ...
> ServletContext context = getServletContext();
> context.getAttibute(...)/setAttibute(...);
> ...
> }
> context is a local variable, but because it references to
> getServletContext(), so perhaps "synchronized" need to be
> used here.
>
>
> have a nice afternoon :-)
>
> Bo
> July 16, 2001
>
> ______________________________________________________________
> _____________
> 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
>
___________________________________________________________________________
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
