With the JSP scope set to request to simplify threadsafe coding and force beans to be constructed and destroyed with each request, will there be negative performance impact?
In general, the overhead of supporting persistent application objects is typically greater than that present in the current approach. Testing has shown that the overhead from the current approach is insignificant when compared to what proprietary, non-J2EE containers previously did, as well as the typical behavior associated with a Web application. In essence, allocation of objects in modern JVMs is a sufficiently cheap operation that justifies the benefits provided by this approach. However, this does not mean that the implications of such an approach has been ignored. Although some non-J2EE containers provided persistent application objects for efficiency reasons, these objects were not stateful to any client. Thus, each client’s stateful information had to be regenerated on each request. Equivalent application objects have been carefully designed with as little overhead as possible. In most cases this is equivalent to the useful, stateful information that must, in any case, be recre
Related Questions
- With the JSP scope set to request to simplify threadsafe coding and force beans to be constructed and destroyed with each request, will there be negative performance impact?
- Is there an example of a shopping cart using Stateful Session Beans and a JSP client?
- How do I install JSP pages and Java Beans in a web application?
