in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 107 108 109 110 111 112 < 113 > 114 115 116 117 118 119 .. 166 >> Next

178 This facility is available programmatically through the 2
request.isUserInRole(roleName) method.
180 -- >
183 <!-- Protect certain pages with a password -- >
184 <security-constraint>
185 <web-resource-collection>
186 <web-resource-name>Flush Cache</web-resource-name>
187 <url-pattern>/flush.j sp</url-pattern>
188 </web-resource-collection>
189 <auth-constraint>
190 <role-name>hero</role-name>
Listing 35.6 (continued)
312 Item 36
191 </auth-constraint>
192 </security-constraint>
194 <!--
196 This defines the way that user logs into the web application. 2
In this case, it uses a FORM, with the
197 login page and error page defined.
199 -- >
201 <login-config>
202 <auth-method>FORM</auth-method>
203 <realm-name>Example Authentication</realm-name>
204 <form-login-config>
205 <form-login-page>/login.j sp</form-login-page>
206 <form-error-page>/error.j sp</form-error-page>
207 </form-login-config>
208 </login-config>
210 <!--
212 This is the place where environment entries can be made for the
web application. This is quite preferable to a
213 properties file in that this is part of the configuration. To 2
read this environment entry you could use these
214 lines of code:
216 String configDirectory = "";
217 Context initCtx = new InitialContext();
218 Context ctx = (Context) initCtx.lookup("java:comp/env");
219 configDirectory = (String) ctx.lookup("configDirectory");
221 -- >
224 <env-entry>
225 <env-entry-name>configDirectory</env-entry-name>
226 <env-entry-value>C:/pitfallsBook</env-entry-value>
227 <env-entry-type>j ava.lang.String</env-entry-type>
228 </env-entry>
230 </web-app>
Listing 35.6 (continued)
Item 36: Too Many Submits
The primary purpose of the Web site today is to display dynamic content. Of course, that means at some point the user sends input to a Web application, the input is
Too Many Submits 313
processed, and the result is returned. Typically, operations on the back end run fast enough that under normal circumstances little can go wrong. However, occasionally, more time-consuming processing must take place—processing that takes more than a second or two. The problem of handling operations that run for long periods of time isn't a new one. Java provides a robust threading mechanism for supporting creating background tasks. Additionally, with the arrival of the EJB 2.0 specification, message-based EJBs can be used to perform background operations. The problem with both of these mechanisms is that they are designed to primarily handle asynchronous operations. You start a thread or background process, and then at some point, you are notified or you check for a result.
The too-many-submits problem occurs when an application is synchronous in nature but still somewhat long-running. Imagine the scenario where a concertgoer logs on to her favorite Web site to order tickets for a show that's just gone on sale. Under normal circumstances, the site performs fine, and our would-be concertgoer purchases her tickets and is on her way. However, when a heavy load occurs, the server slows down, and the buyer gets frustrated waiting for the site and thinks her request to purchase tickets failed. So she hits the Submit button again and again. Unfortunately, earlier requests didn't fail, they were just slow, and so each press of the Submit button ends up ordering another set of tickets.
There are many ways to handle the multiple-submit problem. Two of the most obvious is to prevent the user from submitting the same request over and over. The second is to somehow track that a user has previously submitted a request and revert to the previously submitted action. Figure 36.1 shows the output from a simple servlet that processes the input as it arrives and assigns a ticket number to each request.
C:\WINNT\System32\cmd.exe - startWebLogic.cmd
eader threads) ~Z]
(Jan 12, 2002 2:19:08 PM EST> (Info> <HTTP> < [WebAppSeruletContext (6559849,Def au”"1 ltUebApp,/DefaultUebApp)] *.html: init>
<Jan 12, 2002 2:19:08 PM EST> <Info> <HTTP> <IWebAppSeruletContext(6559849,Defau ltUebApp,/Def aultUebApp) ] **.htnl: Using standard I/’0>
<Jan 12, 2002 2:19:31 PM EST> <Info> <HTTP> <[WebAppSeruletContext<6559849,Defau 1tWebApp,/DefaultUebApp)] SinpleOrderSerulet: init>
(Jan 12, 2002 2:21:06 PM EST> <Info> (Management> (Configuration changes for don ain saved to the repository.>
(Jan 12, 2002 2:21:52 PM EST> <Info> <HTTP> <[WebAppSeruletContext(6559849,Defau ltWebApp,/DefaultWebApp>] SinpleOrderSerulet: destroy)
(Jan 12, 2002 2:21:52 PM EST> <Info> (HTTP> <[WebAppServletContext(6559849,Defau ltWebApp,/DefaultWebApp>] SinpleOrderServlet: init>
Request to purchace tickets for Ozzy
Request to purchace tickets for Ozzy
Request to purchace tickets for Black Sabbath SessionSerulet::doGet
Previous << 1 .. 107 108 109 110 111 112 < 113 > 114 115 116 117 118 119 .. 166 >> Next