Hi,
>Craig McClanahan wrote:
>I use a Hashtable for two different purposes:
>
>* Map from the action name requested to the name of the
> Java class I want to execute for this Action name. I usually
> configure this with servlet initialization parameters, but there's
> lots of choices.
>
>* Map from the action name to the one and only existing
> instance of this action class. I only create such an instance
> the first time this action is requested -- after that, I use the
> same one for all requests, to avoid the object creation
> overhead for at least this one object.
Ok..that makes sense. The second one throws me a bit..what would you only
want to create a single instance of an object that is used by all requests
for? I am sure there are reasons, just that none are hitting me right now.
>If you create a new action instance for each request, then you can
>use instance
>variables in that action. The downside is that you are paying for
>that extra
>object creation (and the ultimate garbage collection) every
>request. This may not
>cost enough to bother you, but it is a pretty easy optimization to
>design in from
>the get-go.
Optimizations..now your talking! To optimize this, you mean use a single
instance of the action class and use local variables? If so, what if two
requests come in at the same time...does the method create local variables
for each call the the method, even if by different threads? I am just
curious because if the same stack is used to push the local variables on to,
what if thread 1 comes in, pushes variables onto the stack, thread 2 comes
in and does the same thing, and now thread 1 finishes up and pops the
variables off...aren't those thread 2s variables at this point? Or is there
a thread-safe mechanism in place with Java and method/parameter stack usage?
>One thing to note about multiple threads executing in the same
>action class at the
>same time (I face this because I only create one instance) is that
>local variables
>declared inside the perform() method ARE safe -- they are not
>shared because local
>variables are allocated on the stack associated with each thread.
Ok..see my above question about the usage of the stack and threads.
>It's instance
>variables where you run into grief. As a practical matter, my
>perform methods
>usually run 20-50 lines (all the "real" logic is done inside
>beans) so I've never
>missed not being able to use instance variables in my actions.
Well, I will agree with you in that we are slowly trying to migrate to using
EJB. So, if I am correct, the EJB should be doing the logic, and the action
class is just a junction between the controller servlet and JSP page, and
the EJB doing the logic..is that right? Thus, the action class links to the
EJB in some way, passing to it the request, or parameters..whatever. The EJB
does the logic, returns info that the action class puts into a JavaBean the
JSP page will use to display. Right? Am I missing anything?
>One more cautionary note -- you still have to be aware of
>multithreading inside the
>objects you store in a user's session. It's entirely legitimate
>for multiple
>requests from the same user to come in simultaneously -- think
>about a framed
>presentation where more than one of the frames is accessing the
>user's session, or
>where the user might have multiple browser windows open (which in
>most cases appear
>to the server as being part of the same session).
Good point. We have that problem with our admin folks using the two
browsers. Using cookies, multiple IE browsers look like the same request.
Sucks. Using URL Rewriting would eliminate this though wouldn't it? I am not
quite sure how to use URL Rewriting though..but if its not too hard, I think
that would be the best way to go. I heard its not any slower than using
cookies, and that it saves the hassle on multiple browsers, and firewall
issues with cookies alike.
>In my case, I pass the servlet, and the HttpServletResponse, as
>arguments to
>perform() along with the request. That means my action class can do the
>RequestDispatcher.forward() thing for themselves -- the controller
>servlet doesn't
>need any special "what do I do after the action method returns"
>stuff in it. But
>that's getting down to personal programming style.
Yeah..I hear ya. The idea I had and the reason I do it this way is so that
each action class just calls setUrl() and they all reuse the single
forward() call in the servlet, and if any error occurs, the url is changed
to either the incoming requested URI, or an error page) and the request
object is set with the exception then forwarded. I agree..its a personal
preference. I just think by placing the forward in the finally block of the
controller servlet, all the action classes reuse the forward mechanism which
they are all going to do anyways.
>Except for stuff you need to save past the end of this request --
>that goes in the
>session.
Right..such as a client information that is used in at least 2 places or
more throughout the site. IN our case, when a user logs in, we keep their
profile in memory because there are many places on the inside they can
change it, and its also displayed in several places, so it makes sense to
keep it in the session rather than keep on getting it from the database.
>Just as an example, let's say you had a multi-page input form,
>because it was too
>complex to get onto one page. I would design a bean that
>represents the input
>values for the entire multi-page form, and save it in the session
>as the user
>navigates between the various pages with "Previous" and "Next"
>buttons.
Exactly! This is what I planned on doing.
>When they
>finally press SUBMIT, and after I process the completed form, the
>bean is removed
>from the session because it's no longer needed. (Note a sublte
>advantage of doing
>this -- the business logic that actually processes the form does
>not know or care
>that the actual UI was split across multiple pages or not; you can
>even change that
>decision later without breaking the logic. Another example of the
>benefit of
>separating presentation logic from business logic.)
Yep. However, we have one little curve in there..on our multi-page forms,
each successive page is "built" from the previous pages choices, and thus
logic is done at each step of the way. However, the entire multi-page forms
all represent one action, and the final submit is when everything is stored.
Thus, we would use a session bean for this. But let me ask you this..being
that I dont know EJB yet. Wouldn't I use EJB to store this information, and
not a JavaBean that the JSP uses? I mean..I would use a single JavaBean with
all the getXXX() methods in it for the JSP page to use and display, but the
actual session data would be kept alive in an EJB and the JavaBean on the
front-end is just used as a place-holder for data returned by the EJB logic
to the action class, right?
Type to you later.
===========================================================================
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
