How can this pool of instances with EJB improve performance?

Question

How can this pool of instances with EJB improve performance? Wouldn't you be able to achieve the same performance with streams only, such as using the Java servlet?

Or is it possible that merging instances with EJB is for a different reason?

Answer 1

I think instance merging is used when beans are expensive to build. By reusing the following query with the same bean, you do not need to create another instance.

If the bean itself is cheap to build, and the cost is what it does, then merging instances is not worth the hassle.

Answer 2

Combining instances helps not only in the fact that you can reuse objects (and avoid the expensive creation of objects), but also the application. the server to properly manage the download . This is the app. server, but you can usually specify max-pool-size , min-pool-size , pool-resize and timeout .

When the pool reaches its max-pool-size capacity, requests are submitted using existing instances and will be absent if the instance is not available in the expected time period. This may degrade the quality of service for the application, but at least it will not blow the application up. server. This is the same as with a web server.

A few notes about thread safety :

Sec. 4.3.13 "Serialization of Bean Methods Session"

The container serializes calls for each Bean session. Most containers will support many Bean session instances running simultaneously; however, each instance only sees a serialized sequence of method calls. Therefore, a Bean session should not be encoded as reentrant.

According to the EJB specification, all requests for a specific Bean instance are synchronized by the application. server. This, for example, allows a non-Bean session (SLSB) to store a database connection in one of its fields. SLSB fields must be temporary. (A Bean instance can be destroyed / recreated at any time.) Synchronized application. The server ensures that SLSB is thread safe. No application sync. server, the developer must make sure that SLSB is thread safe, that is, it should not have fields.

Note: it is rare that there are fields in an SLSB. Most SLSBs are thread safe in nature. I would not recommend storing a connection in a field, for example. It is better to get one in the method and release it in the method as soon as possible.

Answer 3

I think the benefits will be similar to the benefits of the connection pool. Having ready-made instances in the pool avoids the overhead of creating a new instance each time an EJB is requested.

Another advantage, depending on how you look at it, is that by using the maximum pool size, you can limit the damage that the run application can do by making it wait for the instance to appear. This can help prevent poorly written applications from monopolizing server resources.

Answer 4

AFAIK The main reason is the different thread model compared to the servlet thread . In the case of a servlet, there is only one instance, and many threads can work at this level at the same time. The responsibility of developers for proper synchronization lies with the developer.

In contrast, an ejb container allows only one thread to work with a bean instance (including necessary synchronization in the background). Thanks to this, the developer does not have to worry about synchronization, and that more use of synchronization in the bean code is prohibited by the specification (in fact, you can do this, but you must take into account the performance consequences). Therefore, to ensure parallel processing, you need to combine multiple instances of the bean so that multiple threads can access them at once. The size of the pool can be adjusted depending on what work is done inside the bean. The main rule: if the task is related to I / O, you need a large pool so that the processor time is not lost in anticipation of an entry response. If the task is tied to a processor, the pool should be as large as the processors / cores that the machine has. But tuning should be based on measurement.

One more note about servlets: you can apply the same behavior as ejb when using the SingleThreadModel interface. But actually it is not used much, I think.