Entity Bean vs JDBC

Discussions

EJB design: Entity Bean vs JDBC

  1. Entity Bean vs JDBC (7 messages)

    Does Entity Bean contain many overhead? Someone told me that using stateless Session Bean with JDBC to connect to the database is better than using Entity Bean, Is it true?

    Threaded Messages (7)

  2. Entity Bean vs JDBC[ Go to top ]

    This is the difference between a stateful session bean and an entity bean.

    A stateful session bean can only be accessed by maximum one client at any point in time.

    An entity bean represents persistent data that is shared across multiple clients and this data requires transactional logic to it.

    So I would only use an entity bean if you have multiple clients that need to access the same data at the same time and you have to provide the most up to date data all the time and preserve transactions around that data.

    Your friend has a good point, any beans create a lot of overhead. Because they are remote object, means that every call means network traffic.

    A very popular design pattern is to have a stateless sessionbean just retrieve and persist regular java objects representing your data. The only downside here is what if two clients update the same data at the same time. Who ever stores the data last, will win, and the first client doesn't realize his/her data just got over written.

    hope this helps

    Filip
    fhanik at pakana dot com
  3. Entity Bean vs JDBC[ Go to top ]

    The only downside here is what if two clients update the

    > same data at the same time. Who ever stores the data
    > last, will win, and the first client doesn't realize
    > his/her data just got over written.

    Even this can be overcome by using version numbering or timestamp on your data.

    See Long-Lived Optimistic PseudoTransaction (Version Numbering) article.

  4. Entity Bean vs JDBC[ Go to top ]

    well using stateless session bean can be a bit easy but its not prefferable. Entity beans job is to communicate with the Data base. so its good to use Entity bean.
  5. Entity Bean vs JDBC[ Go to top ]

    Entity beans job is to communicate with the Data base. so its good to use Entity bean.


    not really,
    any beans can communicate to anything.

    I stated the difference between session and entity beans above.
    I take it that you decide the design pattern that will fit your business need, I am not recommending a particular one.

    Filip
  6. Entity Bean vs JDBC[ Go to top ]

    I did several tests during the last weeks and did not
    find that entity beans cause so much overhead. Tests
    were performed with WebLogic 5.1 SP5 running on Linux
    and Solaris.

    For example, I tested container-managed persistence (CMP)
    vs. bean-managed persistence (BMP) and vs. a simple data
    class using JDBC with the Ship bean (from the example of
    the book "Enterprise JavaBeans", R. Monson-Haefel, O'Reilly).

    The results were:
    - CMP is faster than BMP, BMP needs more SQL statements
      to do the same test runs.
    - The simple java class using direct JDBC is not
      faster than CMP.
    - Besides that, an important argument for CMP is that
      it took me much less time that all other variants.

    Really nobody observed similar behaviour?

    -- Frank
  7. Entity Bean vs JDBC[ Go to top ]

    I have performed similar tests with Orion and have found this to be true.
  8. Entity Bean vs JDBC[ Go to top ]

    I did several tests during the last weeks and did not

    > find that entity beans cause so much overhead. Tests
    > were performed with WebLogic 5.1 SP5 running on Linux
    > and Solaris.

    Can you send me the test result? Thx!

    email: carsonlam@mail.com