I'm currently in the midst of developing a resonably large model 2 app.
If designed correctly, the controller servlet does not become a significant
performance bottleneck. Make sure that you rigidly define the protocol
between the JSPs and the servlet. We decided to use action classes to act
as the responders to specific requests that come in off the JSPs. Once the
servlet delegates to the action class that class does what it needs to with
the business beans and then routes to the next JSP using the request
dispatcher.
All the controller has to do is match the name of the page request to an
action
class instance and invoke that instance. So, as the app runs, you can cache
the action objects in a HashMap after you first create them, pretty soon all
those
action objects are being pulled from the cache.
So, on the whole my problems with MVC have not been performance related.
However, I am experiencing threadsafe problems I think due to my use of the
request dispatcher - as mentioned just now by Tim.
Under heavy concurrent loads I experience data integrity problems.
Sometimes - and it's very difficult to reproduce - a user will be served
a page that is clearly one that should have been submitted to another user.
What I'm pretty sure this is, is that there is no guarantee that an object
I send onto the Req Dispatcher's queue will be necessarily pulled off by the
JSP it is meant for. Right now I'm not entirely sure how to ensure that
the object returned from a call to request.getAttribute("BusinessBean") at
the top
of a JSP is the one that belongs to this user's session. What exactly is the
relationship between the request dispatcher and the session? Are they
totally
independent of each other? If the request dispatcher should operate within
the
context of a session (which I'm beginning to realize I had been assuming)
then
there may be some issue with my app server (Orion 1.1.37 - a great product
btw)
and it's managment of the request dispatcher queue.
On the whole I've found model 2 a very efficient development paradigm.
But I do have concerns over thread safety.
Any help/comments appreciated
Thanks,
Ferghil O'Rourke
USMoving Inc.
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Fox
Sent: Thursday, August 24, 2000 11:36 AM
To: [EMAIL PROTECTED]
Subject: Re: Model 2 and large applications
see below:
Martin Cooper wrote:
> I am currently looking at building a large application based on servlets
and
> JSP. The principles behind the Model 2 architecture are solid, and this
> seems like the right approach. However, I have some concerns, and would
like
> to hear people's thoughts.
>
> The application I am building will likely comprise somewhere between 100
and
> 150 forms. The use of a single controller servlet, a la Model 2, is
> attractive because it provides a focal point for security and database
> connectivity, amongst other things. However, it raises some concern
> regarding the manageability of so many "entry points" (for lack of a
better
> term).
>
> It seems that I would need some further structure to partition the
> application. I have thought about creating "zones" of functionality, but
> it's not clear (to me, at least) what the cleanest and most maintainable
way
> of doing this would involve.
>
> I have been looking at the Jakarta Struts framework, and very much like
the
> way that forms and actions are hooked up. However, I'm concerned that it
> won't fly for an application with so many forms as I will have.
>
> By the way, this is an intranet app, not an Internet app, and, as such,
> there will be a relatively small number of users. Scalability in number of
> users is not important to me, but scalability in number of forms is.
I don't see that using the model 2 type architecture will have any negative
impact
on the speed of your application.
Just because all requests are being channelled through one servlet (the disp
atcher)
does not imply any any performance degradation compared to, say, calling the
jsp
files directly.
This is assuming the dispatcher has been written correctly - the main thing
to bear
in mind is that your dispatcher must not be a thread bottleneck - this is
ensured
by not storing any state between requests in your dispatcher - ie everything
should
be on the stack.
>
>
> Any thoughts would be very much appreciated.
>
> --
> Martin Cooper
> Tumbleweed Communications
>
>
===========================================================================
> 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
--
Tim Fox (��o)
Hyperlink interactive
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
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
