I would like to raise a performance issue relating to a SessionBean-Stateless, versus a simple Java Bean class. And which pattern is the best by looking to the overhead, ACID and atomic properties e.t.c..
In my current project, the application has got 30 stateless SessionBeans for different purposes in business. But Some consultants are objecting for EJBs as because EJBs are taking a lot of overhead in JNDI lookups and Object creation for each new request or transaction. To eliminate the assumed overhead by them, they are suggesting a replacement for EJBs with Java Beans.
Continuing the deabate on this I am mentioning some of the facts and bebefits we can leverage with the EJBs in comparision to Java Beans.I welcome others to throw some more light on the advantages and limitations on both cases and judge which Bean pattern is best suited for what kind of applications.
-Because of EJBs we can get the best advantage of Object instance management or pool management through the EJB container as it maintains when to create a new instance when some of the object instances are already exist in addition to the other features. Inaddition to this, we have created a java class to cache home,remote and JNDI lookup names explicitly. This mechanism, specific to this application,is to reduce the overhead on the container.
-With java bean, we would be loosing the potentiality of object Manegement because for each and and every new request we have to create a new instance of java bean inplace of an EJB.
-My contention is initially there is an overhead in EJB object creation but as the time goes, multiple instances of EJBs exist they are cached by the container and instead of creating them it will supply them readily with the cached ones rather than creating a new instance. Instace creation is arised when and only to meet the demand of multiple requests keep coming and container has no cached objects for that particular EJB.WIth this we reach a point where in we won't create any new instances at all, untill it is needed.
-But with the simple Java class there's no above mentioned concept, called as Container, eventually we have to explicitly cache them and can't leverage the advantages of the container what it delivers.
Anything other than these features is welcome.
e-mail : email@example.com
I think a simple JavaBean will lack transactions, when you do cluster...I'm assuming you are not clustered yet... configuration-management needs to take overheads of keeping in sync versions of the bean used across the cluster
I don't even think memory/instance management issues are the biggest benefit to session beans. As someone else has pointed out, you get transactions - huge benefit for zero effort (compared to JavaBeans). Also your design is kept architecturally sound/sane - operations on data are defined with the data, in the appserver, instead of in some java bean which is instantiated in every client out there. Thiskeeps your architecture understandable - encapsulation is a great thing - and eases maintenance, since if you change some point of business process, you don't need to upgrade every client, just the session bean.
Is it possible to say <Always use EB> or <Never use EB> ?
Isn't the truth somewhere in between ?
As I understand it you can mix CMP and BMP in one application ? You can mix both with JDBC etc.
Is the answer to closely look at the need in YOU application, so you can mix all of this for the best result ? OK - scalability, but there are some of us using J2EE to build old fascion apps used in Intranet's using Swing clients and I think we will become more and more and we can calculate the need for speed and buy the "right box" almost from start.
I think that sometimes the discussion takes "religiuos" abstract arguments instead of looking for the best solution over all.
For years the I have asked questions like
what is the lifetime for this data ?
will it be changed ? frequently ?
how is it "born" ? who is responisble ? how will it "die" ?
to find out which is the better way of doing things, nomalizing a database, building an infrastructure for an application etc.
Isn't this the kind of questions that could guide us to the right mix of EB, CMP BMP JDBC .....
(hard working newbee knowledgeseeker)
My "without evaluation" recommendation would be: stick with EJBs. I'm quite sure that I never saw a project where they said "replace xy EJBs with normal classes" and it was faster afterwards. EJB systems are amazingly fast if properly designed, and replacing some things with normal classes leads to many problems and makes the whole app lots slower in my experience.
The reason for this is (as I believe) that AppServer vendors know their job, and they put many years into optimizing their servers, so I guess someone shouldn't be that arrogant and think he will be able to do a better job in one month.
You wouldn't think of writing your own database instead of Oracle or DB2, would you?
How can we scale the EJBs performance with an ordinary Java class.Is there any mechansim to scale them apart fro the heap and the memory usage to the total memory. I am using Websphere 3.5v. I am using the resource anlyzer to find out some things but not completely. Can anybody give the balk and whites of EJBs.
I appreciate all of them who gave their opinions by spending their time for this topic.
I have a sales application where I just read the data and for my application scalability & resource management are more important and dont have any need for transaction support so should I go for EJB or normal java beans?