EJB - Performance issue (having more number of EJBs have effect on the performance)?

Configuration and tuning You might need to size the system accordingly. Usually, each EJB has an associated pool (but it's app. Server specific and I have only experience with Glassfish).

So if you have 400 different EJB, that may represent a significant number of object. But all that can be tuned. Local EJB call Regarding an EJB calling another one, I made once a few tests.

Here are the result I got. Time to call one EJB that performs a loop with 10’000 call to another helper object which is either a: Pojo:0 ms Local EJB:63 ms Remote EJB in same EAR:172 ms Remote EJB in another EAR:1735 ms I came to the conclusion that EJB calling each other is not a performance issue if they are local. See also Is it worth to use POJO instead of EJB?.

Deployment & administration The deployment time of the EAR depends also of the number of EJB (to parse the annotations, the deployment descriptor, etc. ). You might make a few tests to see how your app. Server support such deployment.

Monitoring app. With many EJB can quickly become complicated depending on the app.Server. In Glassfish, the JMX console and the web console don't really scale to app.

With a lot of EJB. For instance, the EJB we are interested in need to be selected in a dropdown sometime, which is not convenient when there are a lot of them. EJB/JPA and DAO SLSB responsible of the business logic should be coarse grained.

You can still use fine-grained SLSB for DAO. With JPA, DAO are now really thin and contain mostly JPA queries. It might still be interesting to try to reduce the number of DAO and have some DAO responsible of more than one table, if that's possible.

See JPA/EJB3 killed the DAO.

Thanks ewrnli. Yes, we are planning to have one DAO per table and basically the methods present in these EJBs will be just create/ update/ selectById/ selectAll and delete. And we do not inject (these type of basic EJB) one SLSB in another SLSB.

On top of this we have one more EJB layer which performs bussiness logic operations. We will inject the SLSB (written per table) in the EJBs which perform bussiness logic. Is this correct?

– Kumar Devarakonda Dec 18 '09 at 10:53 I refined my answer – ewernli Dec 18 '09 at 11:12.

JPA is the persistence mechanism normally used with EJB3, JPA-annotated classes are not EJBs. I would tend to express my EJB layer in terms of coarser grained objects. For example Order might be an EJB with an interface expressed in terms of OrderLines, which are not EJBs.

Having said that, assuming that you are using local calls to your EJBs the run-time overhead need not be very excessive. You pay the cost of the JNDI lookups when you get the references, and the container needs to do a little work when dispatching a method (think about security and transactions) so there is bound to be some overhead, whether it's too much for your app only benchmarking can tell.My gut feel: you've got more EJBs than you need, and you will be happier with fewer.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.