Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Enterprise & Remote Computing >> Web Tier APIs

Multiple RequestDispatchers - is it inefficient in a JSP page?

I have a JSP page that processes 3 servlets by using 3 separate RequestDispatcher objects. Is this inefficient?
[118 byte] By [Love2Javaa] at [2007-11-27 6:36:54]
«« Layers jn J2EE applications
»» Determining if a text field is displaying all it's text
# 1
What do you mean?
nogoodatcodinga at 2007-7-12 18:05:03 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2

snippet from example JSP page

<html>

<head>

<%

RequestDispatcher rd = request.getRequestDispatcher("go.servlet1");

rd.include(request,response);

//get request attributes

RequestDispatcher rd2 = request.getRequestDispatcher("go.servlet2");

rd2.include(request,response);

//get request attributes

RequestDispatcher rd3 = request.getRequestDispatcher("go.servlet3");

rd3.include(request,response);

//get request attributes

%>

</head>

</html>

I'm using RequestDispatcher objects to process Servlets. These servlets perform specific tasks, most of which involve requests to the mysql database. The servlets setup some request attributes of which I get by : String name = (String)request.getAttribute("name");

My question : is it inefficient to use multiple RequestDispatchers to process specific Servlets within a JSP page?

Love2Javaa at 2007-7-12 18:05:03 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3

No what you have here is not inefficient.

It may be a little unorthodox, but not inefficient.

Remember that there is only one thread of control here, so it will process each of the servlet requests in turn. You may want to use <jsp:include> rather than a request dispatcher object just so that it users tags rather than scriptlet code (and also has a couple of other housekeeping duties)

The preferred model2 approach is to go to a servlet, and then use the requestDispatcher to forward to a JSP to display the result. What you have here is just a slightly different approach that should work, but is just not standard.

Do these servlets actually do any output?

evnafetsa at 2007-7-12 18:05:03 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 4

> No what you have here is not inefficient.

> It may be a little unorthodox, but not inefficient.

The reason I'm using RequestDispatchers within a JSP page is, mainly, because I used to create Connection/ResultSet/Statement objects in the JSP page, and use them to interact with tables in a mysql database. Which was inefficient...I shouldn't have done database work in a JSP page.

So it was suggested by a member on this forum that I use RequestDispatcher objects instead...so that I could let the Servlet make and close the Connection object, interact with the db and get data, and set request attributes, that I would in turn get in the JSP page.

> Remember that there is only one thread of control

> here, so it will process each of the servlet requests

> in turn. You may want to use <jsp:include> rather

> than a request dispatcher object just so that it

> users tags rather than scriptlet code (and also has a

> couple of other housekeeping duties)

So I could use the <jsp:include> tag to include a servlet...would I still be able to set request attributes in the servlet, and then get them in the JSP page with request.getAttribute(attributeName), as I'm doing now?

> The preferred model2 approach is to go to a servlet,

> and then use the requestDispatcher to forward to a

> JSP to display the result. What you have here is

> just a slightly different approach that should work,

> but is just not standard.

> Do these servlets actually do any output?

Some do, some don't...the one's that don't are used to interact with the db, return data, set attributes (both request and session), and the JSP displays the output if there is any.

Love2Javaa at 2007-7-12 18:05:03 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
Enterprise & Remote Computing
Web Tier APIs

Enterprise & Remote Computing Hot Topic

Enterprise & Remote Computing

All Classified