First, you choose the original JSP/servlet + JavaBeans structure. jsp/servlet is actually a thread. When concurrent users access it, it is a multi-thread. Therefore, in your ProgramFirst, avoid multi-thread access to the same resource, especially the singleton method. This issue has been discussed in the previous post. For example, it was originally a parallel forward and must be made a serial forward when it reaches a render bridge, the performance is greatly reduced.
The best way is to serve an object as a thread, and 10 objects will be accessed when 10 threads are concurrently. This is the most efficient, but pay attention at the same time, if you create a new JavaBeans object every time you access it, it may be a waste of performance, especially for JavaBeans.CodeMany. When there are many functions, the pool is used. When the system is started, the JavaBeans objects are generated in the memory.
The JavaBeans I mentioned above are functional JavaBeans, which improve the performance of functional JavaBeans through pool. Another type is data JavaBeans, which specifically loads data. This part is improved using cache.
The bottom layer of the stateless Session Bean in EJB already has pool support. If you port the code of the functional JavaBeans to the session beans for implementation, it will improve the processing performance of concurrent users and use the local server Load balancer, disable the network performance loss, and disable the slsb transaction mechanism (if not needed), so that the slsb becomes a special ans supported by a pure pool.
Because the bottom layer of the Entity Bean in EJB supports cache, you can use the Entity Bean to implement data JavaBeans cache. However, it is recommended that you do some caching on the web layer, this is the closest to the client, with the best performance.
In short, the performance problem is actually caused by the accidental selection of the architecture. In this forum, we see too many performance problems with JSP + JavaBeans. Why did we start from the beginning of the system, do not choose a scalable and powerful EJB architecture? In this way, when your system expands, you do not have to worry about system performance problems, or even the performance problems cause your JSP + JavaBeans system to fail.