All inline Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Glasser > Sent: Thursday, September 12, 2002 4:39 AM > To: [EMAIL PROTECTED] > Subject: Re: Newbie question: What is the benefit from Entity Beans? > > > On Sun, 8 Sep 2002 19:29:58 +0200, Kriss <[EMAIL PROTECTED]> wrote: > > >Hi all, > > > >after having read some books and articles about ejb, I am wondering > >what�s the benefit from [BMP] Entity Beans and what would > one loose if > >completely leaving them out. > > I asked this same question here a while back and got some > interesting replies. The thread can be seen here: > > http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0101&L=ejb-int > erest&P=R33708 > > My opinion on entity beans is that they were a lousy idea, > from both an architectural and a performance standpoint. A bold remark... > I > have no direct experience with CMP, but from what I've seen, > I doubt that it's used successfully for many large-scale > projects--there's always going to be some kind of custom > business rules that need to be applied when an object is saved, etc. I see this a lot... People first make a bold remark, then issue a disclaimer ;-). I have used CMP in large scale projects. It works. Optimizations were needed in a few, very distinguishable spots. The rest of the performance problems were due to using the wrong architecture, which was fixed by refactoring and dumping parts and code from scratch; since CMP was used, it didn't consume large amounts of time. > > For my first big J2EE project (when I first posted the > question about entity beans you're asking now) we decided to > avoid them entirely. On my second one (which wasn't as big as > the first) we had to integrate with an existing system that > was using them, and it wasn't bad because we only had to call > a few that were already written, and the system wasn't > high-volume enough that the entity beans created a > bottleneck. The project I'm on now, which is fairly > large-scale and which I joined sort of in the middle, uses > them everywhere, for practically every database read and > write in the system. When I see how heavily the database gets > hammered for the simplest things, well, let's just say I have > "concerns" about how well the system will scale once it's deployed. Are entity beans to blame here or poor architecture? I know a lot of non-J2EE systems that hammer the database as well. Also some EJB containers have strict implementations that do not help much. > > Let's say you have a Customer entity bean, and for a > particular customer you want to change the first and last > name. Here's what happens, at least in Websphere running within WSAD: > > 1. Assuming you have the home interface already, call > findByPrimaryKey with the customer's PK. > * Within ejbFindByPrimaryKey, you use the pk fields to select the > pk fields from the customer table. Or you can do a select > count(*), to simply verify that it's a valid pk. > * The container will then call ejbLoad(), where you read all of > the data (hit number 2 on the database) and populate the bean's > fields. A remote reference to the bean (the remote interface) > is returned to the caller. > 2. The application then calls setFirstName(String) on the Customer > entity bean. > * Even though the bean's fields are already populated, Websphere > decides to play it safe and call ejbLoad() again, incurring the > third database hit. > * The container forwards setFirstName() call to your bean class, > where the field get's changed. Then ejbStore() gets called to > update the row for that customer. (But keep in mind that only > the first name gets changed this time. > 3. The application then calls setLastName(String), and the ejbLoad()/ > ejbStore() cycle described in step 2. is repeated, for database > hits 5 and 6. That's just Websphere in a very strong database integrity mode. I've used other servers and they implement the contract more eficiently. Orion(OC4J) has an "exclusive-write-access" mode in which there is only ONE read op. and a WRITE op. every N seconds. > > So here you've incurred 6 database hits (two of which were > updates) to accomplish this: > > UPDATE customer SET first_name = 'Bob', last_name = 'Smith' > WHERE customer_id = 12345. > > Multiply that by a thousand users and draw your own conclusions. OK. 6 x 1000 = 6000. 1 x 1000 = 1000. Thus you have something that performs 6 times worse than hand coding everything(let's ommit the fact that updates are much more heavy than simple select statements). It's still within the same order of magnitude. Also bear in mind that the simple UPDATE statement is optimistic locking of the database. It's not my intention to defend Websphere here, but to point out that this kind of performance degradation may be acceptable, especially on large scale projects; because usually large scale projects prefer hardware upgrades to continuous improvement(there's always a mix, but hardware is cheaper overall). This doesn't cover them for using the wrong architecture, which often impacts performance in an order of magnitude. > > Now before anyone chimes in about bulk accessor methods to > update multiple fields with a single call, and clean/dirty > flags to save unneeded updates in the ejbStore() method, I > already know about them. But I have little patience for a > design that requires me to go through so many gyrations to > prevent it from being a total dog performance-wise. Heck, > Websphere/WSAD even calls ejbStore() after a getter method, > which doesn't even change the bean, is called! (To be fair, > though, it has no way of knowing whether the bean has been > changed or not.) It could, with a clean/dirty flag ;). > > Consider a scenario where you want to cancel all of the items > on a customer's order, and this involves setting the STAT > field of the ORDER_ITEM table to C for each cancelled item. > Let's say instead of doing this: > > UPDATE order_item SET stat = 'C' WHERE order_num = 12345; > > A design document has been handed to you dictating that it > must be done through entity beans. Here is what would happen: > > > ejbFindByOrderNum() > SELECT order_num, item_num FROM order_item WHERE order_num = 12345; > // Return an Enumeration of OrderItemPK objects for each row in > // the resultset. > > ejbLoad() > SELECT * FROM order_item WHERE order_num = 12345; > // this select will be executed once for each item on the order, > // IOW 10 items = 10 selects. > > ejbStore() > UPDATE order_item SET ... etc. > // this will be executed once for each item on the order also. OK, so WSAD only supports EJB 1.1-- you can do this easily with EJB 2.0. Yet the point is valid. The approach I've used before is: do everything with EBs. If something really needs optimization, revert to a SLSB and SQL(if possible a SP). > > And then don't forget the overhead the container incurs for > managing the lifecycle of all of your short-lived OrderItem > beans. Of course, somebody might argue that you need coarser > granularity, and you should just have an Order entity with a > cancelAllItems() method on it. They would be right, too, but > the more you move toward things that make sense, the farther > you're moving away from the basic entity bean model, so > what's the point of using them at all? Well, I agree here. But the point is not that EBs are a silver bullet in performance terms, but that they abstract the persistence logic, are clearly defined by the spec, and are so much easier and faster to code with than SQL(if you're using CMP). Granted, if you're using BMP, then you have to code all that SQL anyway, but at some point(pushing the logic to the limit) you wind up writing a SQL chuck for each use case. Also (something SBs do) handle transactions transparently, handle security transparently. > > My advice to you is to not use entity beans, for anything, at > all, period. For all of their downsides, I have yet to > comprehend a single advantage that is gained by using them. > If you're using BMP, the single advantage is you could migrate to CMP EBs seamlessly or almost seamlessly. They're easier to maintain than raw SQL commands, and they open the game a lot in a large scale project, where the providers of each Enterprise Class Service change a lot. I mean management cutting a deal with Oracle to be their DB and the migration from DB2, getting Ariba to work with your project, pluging into SAP, etc. And with CMP, everything is easy to understand and maintain, and use cases and BL is completely contained in Java classes. If you're looking at EBs expecting to find an improvement in speed of execution, yer in for a lot of disapointment. And until everybody catches up with the specs, many of the other benefits will be offset'd. Let me try to explain what I'm talking about. Scouting for programmers for a large scale prj. 3 years ago was about getting: Guys that knew: Java OR C++ OR VC++ OR VB. SQL (the particular flavor for the DB that was chosen) OracleForms OR HTML OR Swing OR M$Forms. And of course, as well as 4x4 programmers, you also needed specialist in each area (1 or 2 DBAs, GUI Gurus, Software Architect) With J2EE, the requirement is to know Java and to deeply understand the spec OR use the right tools(I like Pramati Studio a lot, esp. since the last prj. I've been into was a reasonably low number of entities ALL interconected). That's the benefit. That's the improvement. That's why J2EE became what it is today. It's simpler and it's cheaper and it allows for more control after going live with your prj. And should people in the original crew decide to leave or whatever, it's still manageable by people coming into the project. Most of the benefits here are payed with small degradation to performance, and in a large scale prj. that's acceptable because in the big picture the cost is minimal(without pushing; when you need optimization, you optimize). My 2c, ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
