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-interest&P=R33708 My opinion on entity beans is that they were a lousy idea, from both an architectural and a performance standpoint. 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. 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. 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. 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. 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.) 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. 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? 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. ==========================================================================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".
