Please tell I'm doing something wrong and ejbs don't suck that much

[Balamaci Serban]

This cannot be true, i'm sure i'm doing something wrong.
In my entity bean, I have a method

 
public Collection ejbFindAll() throws FinderException
    {
      Connection conn=null;
      Vector v=null;
        try
        {
          v=new Vector();
          conn = getConnection();
          Statement st = conn.createStatement();
          ResultSet rs=st.executeQuery("SELECT id FROM persoane order by id");
          while(rs.next())
          {
           v.add(new Integer(rs.getInt(1)));
          }
        }
        catch(SQLException ex)
        {
            System.err.println("Eroare ejbGEtToatePersoanele "+ex.toString());
            throw new FinderException(ex.toString());
        }
        catch(Exception ex)
        {
           System.err.println("Eroare ejbGEtToatePersoanele "+ex.toString());
        }
        finally{
            try {
            conn.close();
            }
            catch(SQLException e)
            {
                System.err.println("Nu am putut inchide conexiunea");
            }
        }
        return v;
    }

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()

 
    public void ejbLoad() throws EJBException {
        Connection conn=null;
        try
        {
          conn = getConnection();
          Statement st = conn.createStatement();
          System.err.println("in Load");
          String str="SELECT nume,cnp,adresa,localitate FROM persoane where id="+ctx.getPrimaryKey()+" order by id";
          ResultSet rs=st.executeQuery(str);
          rs.next();
          this.id=(Integer)ctx.getPrimaryKey();
          this.nume=rs.getString(1);
          this.cnp=rs.getString(2);
          this.adresa=rs.getString(3);
          this.localitate=rs.getInt(4);
        }
        catch(SQLException ex)
        {
            System.err.println(ex.toString());
            throw new EJBException(ex.toString());
        }
        catch(Exception ex)
        {
           System.err.println("Eroare ejbLoad "+ex.toString());
        }
        finally{
            try {
            conn.close();
            }
            catch(SQLException e)
            {
                System.err.println("Nu am putut inchide conexiunea");
            }
        }
    }
 

I must be doing something wrong. There is no way ejb could do this. Wright?
[ March 27, 2005: Message edited by: Balamaci Serban ]

[Valentin Tanase]

Hi 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.

[Balamaci Serban]

Thanks Valentin. I was kinda hoping i'd be wrong.:

Here from http://www.precisejava.com/javaperf/j2ee/EJB.htm

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 ]

[Merrill Higginson]

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.