Ok. That's what I'll do. Right now I have the following
at the top of each action class perform() method:
super.getMasterBean( httpreq );
A parent method which essentilly fills in the master bean reference
for this action object.
I'm going to replace this in each leaf action class with the following
(essentially the contents of the parent getMasterBean() mehod:)
HttpSession session = req.getSession(false);
MasterBean mBean;
if ( session != null )
mBean = (MasterBean)session.getAttribute("sess.masterbean");
I have a "warm feeling" that this is going to fix my problem.
I won't know the result until we do our next stress test.
But thanks for all the comments.
Much appreciated.
-Ferghil
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Craig R. McClanahan
Sent: Thursday, August 24, 2000 3:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Model 2 and large applications - and request
dispatcherthreadsafety
Ferghil O'Rourke wrote:
> Craig,
> My parent action class has private instance declarations.
> The central one is my "master" bean, the one that essentially
> controls (and contains a reference to) all the business beans
> in the session.
>
> I think my problem then is as you stated it. Because I am caching
> the action class instances there is only ever one instance of any
> given action class type. Therefore it is possible that a user
> request could be issued to the controller servlet and be assigned
> an action object instance that is currently being used by another
> user, and therefore it gets a copy of the wrong "master bean."
>
Yep ... this is very likely the culprit. Any time you have requests from
two
different users being handled at the same time, they are going to fight over
who
controls the "master" bean.
> Does this mean that I should move this parent instance declaration
> down into local space in each of my (many) action leaf classes?
> This would require a lot of inelegant boilerplate code to access
> the master bean in the local action class perform() methods. Ugh.
>
That would be my recommendation. We're only talking about one line of
boilerplate
code, though. Assume that your master bean is of class MasterBean, and it's
stored
in the session under key "master". All you need is the following at the top
of the
perform() method:
MasterBean masterBean =
(MasterBean) request.getSession().getAttribute("master");
Because this is declared *inside* the perform method, it is a local variable
and is
specific to the current request only, instead of being shared.
>
> Is there any other way around this? What about making the parent
> declarations synchronized? Or maybe abandoning the caching
> of action objects - new instance per request. Just ideas.
> Performance issues on both mitigate against I suspect.
>
Synchronizing here would be the web application equivalent of designing a
supermarket that only has one checkout counter. It pretty severely limits
how many
simultaneous users you can support with reasonable response times ... ;-)
>
> Thanks,
> Ferghil
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
