This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This cannot be true, i'm sure i'm doing something wrong. In my entity bean, I have a method
Now every time i call that one, the ejbStore() fires as well for every entity beand retrived from the database. And the screen gets full with "UPDATE persoane SET ...." Is that necessary? For me it would be a total killer. I just want to get the records. I'm not changing nothing in them, so why have another trip to the database, to update something that has not changet at all?
Here is ejbLoad()
I must be doing something wrong. There is no way ejb could do this. Wright? [ March 27, 2005: Message edited by: Balamaci Serban ]
I must be doing something wrong. There is no way ejb could do this. Wright?
Wrong actually, because this is exactly what entity ejbs suppose to do. The container calls ejbLoad at the beginning of the transaction in order to get the latest data from the database. At the end of the transaction the container calls ejbStore in order to save the data into the database. This is what the specs say and this is what the containers usually do; this is the infamous n+1 selects problem with entity ejbs. However there are works around this problem with CMP. The container might choose to retrieve the data in one single bulk jdbc query. WebLogic for example has a special flag that could be set in order to enforced this and avoid the n+1 select problem. However there is no way (or at least I don�t know any) to avoid this problem with BMP entity ejbs. This is only one example that leads the conclusion that a project using BMPs is mostly condemned to fail. It also leads to the conclusion that a persistence solution using entity ejbs must employee vendor specific solutions in order to be competitive. Regards.
I think, therefore I exist -- Rene Descartes
Joined: Mar 16, 2005
Thanks Valentin. I was kinda hoping i'd be wrong.:
Use dirty flag to avoid unchanged buffer data updation
EJB Container calls ejbStore() method when the business method execution completes or when the transaction completes irrespective of change in the bean's data. The entity bean's data may not change every time when the client calls the business method. So there will be lot of updates ( calls to ejbStore() ) to the database even though it doesn't require, thus degrading performance. To avoid this problem, you can configure dirty flag property in vendor specific deployment descriptor file for CMP1.1, for example is-modified-method-name in weblogic server's weblogic-ejb-jar.xml file. For EJB2.0 CMP, it does not require to configure because EJB2.0 CMP Container supports this feature implicitly. For BMP, you need to write this method in bean's class and call this method wherever necessary. This technique reduces calls to the database unless the bean's data changes, thus improving performance.
And bottom line kinda:
One of the CMP performance improvement technique in EJB2.0 is that the Container can monitor bean's data (in-memory buffer) change and if any changes happens in that data then only Container will update the database. Because of this monitoring capability, CMP gives better performance than BMP. And another technique is when you call finder method in BMP, it initially retrieves primary key with first call to the database and then instance data by placing a second call to the database. It makes two calls to the database. But CMP gets the data with single call to the database for the finder methods. Thus CMP gives better performance than BMP because Container has good hold on CMP.
Well my world kinda crumbled after that one. It really kinda makes me wonder about the usefullnes of entity beans.I thought that by caching them would make a real improvement on selects. Turns out that the optimised use pattern is to read in a sesion bean outside of the entity bean and go for direct jdbc calls that use powerfull database caching mecanism when you use prepared statements, not through the getAll() method of the ejb. Why would i use an entity bean for then? So that instead of writting one line SQL and isolate it in a transaction i would go for looking up a home object and call a method on the bean so that it would be more OO like?
Maybe CMP beans look more atractive. I can't use them in my project. I thought of using JMS to pass the SQL to replicate to other servers in the ejbStore(). Anyway i still see sql instructions, they are now called EJB-QL, got to learn that too-yeah right-, should we? We already know JDBC and the 3.0 has some nifty features i would like to have control over them myself. Well right now i'm stuck with them so i'll stop my bitchin.
Well the ejbStore() is not so bad. I think i resolved it with implementing another private variable private boolean isDirty;
In ejbLoad() i set it to false. On any method that changes the data, i set it true. In the ejbStore() first instr. is if(isDirty) then u may enter. Hope that does not rise any problems. It can't i guess. Still.... [ March 27, 2005: Message edited by: Balamaci Serban ]
I know IBM allows you to declare a method in an entity bean as "read only", meaning that it will not call ejbStore() every time it executes. It's not part of the spec, but it's handy in a situation like this. Other Application servers my have similar features.