• Post Reply Bookmark Topic Watch Topic
  • New Topic

Differentiate the ("use of EJB" vs "do not use EJB")?????  RSS feed

Christina Sanyos
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Differentiate the ("use of EJB" vs "do not use EJB")???
I know using EJB uses considerable system(web server)resources. Whats
the exact! demarkating line that we can differentiate the "use of
EJB" vs "do not use EJB".
The scale of the application determines the above question.
I came up with the following criteria that are factors to determine
the scale of the application:
(1). Number of records in the database(millions), if so how many
millions of records should be in the database???
(2). Number of clients accessing the application. How many clients
accessing the application would make you make your choice???
You can still develop an application that is robust with just a
normal, JSP, Servlet model. But it may not be that scalable.
Please post your opinion.

Joel McNary
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To my way of thinking, the number of records in the database should not have any bearing on whether or not to use an EJB or "direct-from-servlet" approach. In fact, the more records there are in the database, the less desireable EJBs become! (If you are doing batch processing (and with many records in the database, you will be doing batch processing), (Entity) EJBs are just about useless.
The real driving force is the number of users. With only a handful of users, concurrent-access is not that large an issue. As the number of users grows, however, you should start thinking in terms of EJBs for data access and calcualations to ensure that your users are happy users.
So, in terms of actual numbers, I would say to use EJBs whenever one of the following:
a). You have more than one physical area where clients are located, (multiple offices, etc.)
b). You have data that is gaurenteed to be hit/modified by more than one user at a time (e.g., sequence number management if your DB does not provide its own mechanism).
c). You have more than five simultaneous occasional users. A handful of users will put up with pessimistic locking (no, you can't work on that record...get Bob to log out first) than a larger number. Of course, if this is an application that they are going to use all day every day, you might want to consider using EJBs even if there's only two users.
or d). Your manager insists If you (or your manager) think that the project is going to grow, use EJBs even if they would not be required for the "right now requirements." There's no telling when those requirements will change.
Those are my thoughts. Anybody else?
Bear Bibeault
Author and ninkuma
Posts: 66207
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While this is probably more appropriate for the J2EE forum, I'll chime in.
I've worked on 7 large scale projects that meet any criteria you could find for using EJBs (except specious ones like "my manager insists"), but in all but one case we concluded that the use of EJBs was simply too complex and with too much overhead and development pain. It was simpler and faster to use home-grown solutions. (That of course implies that you have a mature staff that can handle such a task. The competency level of the staff is another factor that goes into such a decision.)
It's certainly not an easy question to answer. I highly recommend moving this to the J2EE forum where a diversity of informed opinions can be garnered.
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!