Discussions

EJB design: JDBC v/s EJB

  1. JDBC v/s EJB (10 messages)

    I am presently working on a project involving EJBs. I am yet undecided regarding what are the scenarios to use JDBC and in which scenarios to use EJBs? The above decision needs to be make taking into consideration the performance issues.

    Threaded Messages (10)

  2. JDBC v/s EJB[ Go to top ]

    Your question is kind of ambigous.

    I guess what you mean is whether to use JDBC in your applications or CMP Entity Beans. If thats your questions then, what u shud choose is entirely based on the kind of applications u have. Arguments acn be placed both for CMP or JDBC.

    My .02 on this is that if you have a high transaction application which is consistently writing lot of data to the database, then u will be better off going the JDBC approach.

    On the other hand if your application is more of read-only application and does more of read operations on the database then Entity beans is not a bad option.

    let me know if i understood ur question correctly.

  3. JDBC v/s EJB[ Go to top ]


    <Kapil Israni>
    My .02 on this is that if you have a high transaction application which is consistently writing lot of data to the database, then u will be better off going the JDBC approach.
    </Kapil Israni>

    What is the reasoning behind your such broad statement?

    Even for high transaction applications, if I use entity beans with commit option A, I get the added benifit of the container caching my entity beans. It saves an extra trip to the database through ejbLoad() for the next transaction, provided of course no other app is updating the database.

    Pranab



  4. JDBC v/s EJB[ Go to top ]

    I suggest that you take an XP approach. If your data can easily be represented in CMP, use CMP, as it is easier to code. Then if your application is not fast enough, responsive enough, or efficient enough, tune only the sections that don't meet you requirements.

    You may find that converting to JDBC does not solve your performance problems. Most EJB servers have an internal cache and query optimizer, and without these your code may be slower.

    CMP does not handle some data, such as streams, well; in that case, you may want to use JDBC directly.
  5. JDBC v/s EJB[ Go to top ]

    Set a side choosing whether or not to use EJB at all (because it seems you allready chose EJB) I would suggest using CMP as long as it can meet your requirements. I don't find the performance of CMP to be an issue in most cases - and you can allways optimize after having written the code. When you can't use CMP, because of complex data structures or complex/dynamic queries, JDBC is the only way to go.

    Just my 0.02

    Gal
  6. JDBC v/s EJB[ Go to top ]

    In my experience a combination of both can be useful. I have used CMP as they are quick to implement and you get a lot from the App server without having to do any work.

    However, for times when I need data that is not easily represented within one bean (ie: a lot of specific data, or a query that spreads across multiple tables) I will use a Home method which returns a CachedRowSet. This way I can keep all the data access in one layer but can be flexible in how that access occurs. It works well.

    Darren.
  7. JDBC v/s EJB[ Go to top ]

    Interesting. Can you explain the benefit of using an entity bean home method vs. a regular stateless session bean method? Is it just personal preference?
  8. JDBC v/s EJB[ Go to top ]

    Hi Eric,

    Re: using an entity bean home method vs. a stateless session bean.

    I chose to put JDBC within home methods as opposed to S'less SB's so that I could keep the code in our app truly tiered. I wanted to have all presentation logic within JSP's, all business logic within SB's and all database access within EB's. I could have put JDBC within the SB tier, but then I would have had my DB acess spread across multiple tiers which would have been messy.

    Also, our EB tier is aimed at multiple applications, not just one, whereas our SB's are more tailored to individual applications. To avoid duplication I thought the JDBC would be best left within the EB's.

    What are your thoughts?

    Darren.
  9. JDBC v/s EJB[ Go to top ]

    Sounds like a nice and innovative strategy to me. Thanks for sharing the info.
  10. JDBC v/s EJB[ Go to top ]

    i just want to get a book
  11. JDBC v/s EJB[ Go to top ]

    If you need to write/modify the data quite often then JDBC is better if you need to read the data more then entity beans would be a better choice.