Should I use a CMP Entity Bean or straight SQL in design?


EJB programming & troubleshooting: Should I use a CMP Entity Bean or straight SQL in design?

  1. I'm writing a simple demo J2EE application to use for internal company usage (PetStore wasn't useful for us anymore) so it doesn't have to be bulletproof code. And to demonstrate different J2EE concepts I may use different ways of doing things where it may be better served doing it another way. question is I'm trying to determine whether I should use a CMP Entity bean to model a database table, or should I use a DAO and write some SQL to INSERT & SELECT.

    I need to log transactions of actions performed(date, time,etc) to a table and then later display them if the user wants to view their transactions.

    I initially thought of doing it the following way: JMS & a MessageBean. A JMS ObjectMessage is sent containing the transaction to a MessageBean. The MessageBean receives the message & uses SQL (PS) to write the transaction to the DB. When the user wants to view the transactions, another SQL query (in a different class) gets the transactions (recordset)for that user & displays to webpage. I liked this way because it would allow me to demonstrate SQL & Message-Driven Beans which I haven't used in the demo app yet.

    Then I thought about if I was going to architect this correctly, I would probably make a Transaction CMP EJB for each record in the table. Collection via ejb-ql would be used to harness all the transactions for the user. I'm concerned about this causing excessive load with many transaction records(or maybe this isn't an issue at all).

    Then I came up with a hybrid of the 2 it possible to use the message bean & sql to insert new transactions to the DB, yet use CMP EJBs to display the transactions? I'm worried about the EJB getting out of sync & not refreshing after INSERTs are done via SQL. Is this possible? Seems messy.

    What would you recommend? Remember that the technically correct way is not essential, but it would be nice to stay as close to that as possible since this should be a reflection of "the way things would be done in the real-world".

    Thanks. Blaine.
  2. Hi,

    Those are some good questions. There are trade-offs to either approach.

    Generally speaking, I would use an EJB in situations where I know that I'll be routinely selecting and operating on a single entity, or at most a small list of entities. Conversely, situations that call for the selection of large subsets of entities, or mass updating of entities, might be better served by a non-EJB approach.

    If you do use an EJB, it's bad form to write JDBC code that updates an entity outside of its EJB implementation. You can certainly get away with this if you want to configure your EJB container to have non-exclusive access to your database, but that will vastly increase your overhead, and it more or less breaks the spirit of EJB. When using an EJB, the right approach is to consider the EJB to be the authoritative source of the data, not the database. An EJB is supposed to be able to hide its underlying implementation from its client. In theory, the user of an EJB shouldn't know or care what database the data is coming from, or for that matter if it's even coming from a database at all.

    There are various optimizations that people have come up with to deal with EJB's shortcomings, such as the fat-key approach. My opinion is that if you have to rely on these optimizations to get anywhere, then EJB is probably the wrong choice for your application.