EJB design: How to respond to "Entity Beans are memory hogs"?

  1. How to respond to "Entity Beans are memory hogs"? (1 messages)

    So, if someone with experience implementing web applications downplays EJB, and entity beans in general, by saying "Entity Beans are memory hogs", how do you respond to that? This is in the context of implementation in either Weblogic or JBoss.

    Are there any definitive statements you can make to refute that, at least wrt present implementations?
  2. Hardware is cheap. Ludicrously so.

    Point solutions are not, certainly in the long run.

    EJB (J2EE in general) allows one to design systems that can be re-used and re-factored easily thus speeding development cycles. Thus saving much more expensive (than hardware) developer time.

    To put it into executive-speak: Total Cost Of Ownership.

    Another question I ask you is why is this person making this assertion. Sometimes you get people who just stick to their particular prejudices, e.g. Java is slow, etc.

    A properly design J2EE system won't use excessive amounts of memory, well certainly they do require LOTS of memory but if the system is designed correctly then it should not use "more than its fair share" vis-a-vis what the system does. Minimally an EJB Container isn't really going to run terribly successfully on less than 512Mb but hardly any modern commercial systems do anymore. (bear in mind there are still people around who think that the goal is to have an enterprise system run in 16Mb of memory, that's a philosophical difference that may be hard to overcome).

    Perhaps this person had encountered a poorly designed EJB system in the past and had seen poor performance and excessive memory use due to teh design flaws inherent in the system; eg "everything is an EJB" type design, using FindAll methods (instantiates all rows of db as beans) and so on.

    Maybe simply ask them to provide some evidence or substantiate their claim, or are they the "beyond reproach" type technical guru in your organisation?