Entity Beans Vs JDBC calls


EJB design: Entity Beans Vs JDBC calls

  1. Entity Beans Vs JDBC calls (12 messages)

      I am in a situation in a project where I have a team of technical people saying that that using Entity BEans only buys you more problems. They opinions is to use SQL from sessions beans..
       We are using Weblogic 5.1 as our app server.
       I am looking for opinions and any bad experiences anyone has gone through using entity beans in weblogic.

    Thanks in advance,

    Threaded Messages (12)

  2. Entity Beans Vs JDBC calls[ Go to top ]

    Hi, Sriganesh Sundaram:
      I don't think using Entity Bean (especially CMP) is a bad idea at all when the persistence requirement is not very complicated. If you have VERY complex business logic that requires many different transaction cases on one business entity (which is a good candidate for a Entity Bean in most situations), I will go to use session bean + my own SQL + even my own Stored Procedures (it's not Portable, but sometimes you have to take it for performace, especially for batch process). Combination of both is another alternative if you insist on sharpenong your J2EE skill (kidding)...

    Keep in touch,
  3. Entity Beans Vs JDBC calls[ Go to top ]

      Somebody comment on this.This is an interesting topic...

      Because i think calling SQL directly from a session bean is NOT a good programming practise. I would have gone for a Entity bean which has all methods to access data from a particular table.A session bean will query the database via this Entity bean.

      Again,this is my personnel opinion.I would really like someone to put more light on this.I would like to know if my thinking is right.

  4. Entity Beans Vs JDBC calls[ Go to top ]

    Using Sessions beans for DB calls may not be a bad idea, over Entity beans. I would say it really depends what are you trying to do - "select", "insert" or "updates". I think Entity beans are more useful when you are doing updates. There is a big overhead on "inserts" as all the calls to the DB are synchronized in the Home Object implementation and there is only one instance of the Home Object for a particular Entity used by the clients. for "selects" I would use Session beans. And mind you, their is nothing wrong in writing session beans with direct DB calls, Can the person who said it is a bad programming practice explain me Why? Use Sessions Beans + DOA to have good OO approach. Thats my suggestions.

  5. Entity Beans Vs JDBC calls[ Go to top ]

    Calling JDBC through session bean is not a bad practice.But I have a question..

    I have 4 tables in the back end.All the tables connected with a key called 'loginid'.
    I want to insert data into these tables using a single form(JSP+HTML).How it is possible with session bean?

    Does session bean JDBC calls serve for multiple tables?

    Thanks for your time
  6. Entity Beans Vs JDBC calls[ Go to top ]

    All those guys who are saying Use Entity beans, guys do not forget that there is an overhead with using entity beans, each call is a remote call. On the other hand, you may use a session bean with Data Access Objects to reduce the remote call overhead. Again, please tell me why you people think using entity beans is better. I think it really depends on what kind of Data Model you have? For lots of concurrent updates to a row in table, probably entity beans would be better, for "select" and "insert", I would go with Session beans. Please comment.
  7. Entity Beans Vs JDBC calls[ Go to top ]

    Its ok

    But I want to insert data into mutiple tables using a single form.Which one you will prefer?Entity or session?

    Session bean doesn't support Primary key.So the ultimate way is to get entity bean.Rite?
    Please comment..
  8. Entity Beans Vs JDBC calls[ Go to top ]

    I think the whole idea of decoupling your business logic from your database access logic makes Entity Beans a better choice than session beans using JDBC.

    Could you please explain how session beans using JDBC has less overhead compared to Entity Beans? Thanks.

  9. Entity Beans Vs JDBC calls[ Go to top ]


      I didnt know this discussion would go so long.....

      OK, what i said in my previous message was that using EntityBeans to access values from database is a BETTER PROGRAMMING PRACTICE.I did NOT say its not possible to access database from session beans.

      GOOD PROGRAMMING PRACTICE is to separate bussiness logic from persistence logic.So in persistence logic,u can go for a Entity bean which has all methods to retrieve/store values from/to database.And in bussiness logic u can go for a session bean where u should write code to do some manipulation with this data.

       Suppose i have a table called USER_TABLE which contains all info about users(say,name ,id,username,passwd,address,salary,overtime),i would go for an Entitybean called say,UserBean having getXXX()and setXXX() methods for each field.If i want to manipulate the data,i would go for a SessionBean called say,UserBeanManager which has methods CheckIfValidUser(),CalculateXXXXwithSalary()....etc. I hope i made my point. If anybody disagrees,please respond. Viji
  10. Entity Beans Vs JDBC calls[ Go to top ]

       Using entity beans for persistence is much better option that making SQL calls from ur Session Bean . I have been using Entity Beans(mostly CMPs) in my last 2 projects and I haven't faced any problems. If the Business logic is quite complex and ur queries involves too many joins and nested queries , u can go for TOPLink for Object to Relation Mapping , using this u can get all the data from any number of tables in one class and then u can use ur session bean to access this data and modify it as mentioned by Viji. This way u draw a clear line between ur business logic and the broker layer, which is very important if you want to make ur application easy to scale and maintain.

  11. Entity Beans Vs JDBC calls[ Go to top ]

    My suggestion for the original question would be to go ahead and begin modeling the domain for which you will be developing and then try some of the object-relational tools such as TOPLink or Cocobase, as this gives you very efficient sql transactions with connection pooling and caching, but doesn't tie you to entity beans if you are concerned with scalability.
    I am still fairly convinced that Entity Beans are overkill for most situations, unless you need some of the transaction management features of Entity Beans, but that Session Beans are invaluable for most Weblogic-based applications.

    Clay Roach
  12. Entity Beans Vs JDBC calls[ Go to top ]

    Hi all,
    Entity beans r a good solution when

    1. your tables have transactional requirements.

    Entity beans do add overhead compared to (session beans + jdbc). but this overhead significantly reduces when the rows of ur tables are

    2. likely to be accessed by many number of clients.

    3. the rows of the tables r in such a way that a fraction of the rows r accessed more frequently.

       this is because most of the app servers cache the entity beans. so, if ur rows are accessed by multiple clients and if some of them r accessed quite frequently, the container need not hit the db everytime and can instead get it from the cache.
       if this not the case with ur data, session beans + jdbc is definitely the better solution. only a proper analyses on ur data can reveal u, which solution is better. and typically in any project, both the solutions coexist.
       also while using entity beans the features provided by the app server shud be exploited for performance. (like isModified(), dbShared=false).

       with app server's on EJB2.0 coming up in due course, entity beans(CMP), wud become more common, as it wud satisfy the promises of providing a domain model for the application, allowing the developers to concentrate only on the business logic and relieving them from the responsibilities of persistance.

       open for everyones comments
       thx, manohar
  13. Entity Beans Vs JDBC calls[ Go to top ]

    Great.Right explanation.