Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We are developing an application with around 400 database tables.
and have equal number of EJBs (All are Local interfaces and EJB is stateless) and one EJB is injected into another EJB by @EJB tag.
My doubt is, is having more number of EJBs have any effect on the performance on the application?
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:
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.