Potential Enterprise Java Bean

Here's the goal. The simple goal is to display a web page. Break that down into the processes.

1. Get requested info from user, what he wants to see.
2. Make the calls to the database via JDBC.
3. Walk through the result set and instantiate objects that are readable by our SimpleThinJavaServerPages.
4. Make any additional database calls to fill in sub-info.
5. Release the database resource.
6. Return control back to the App Server Framework that executes the JavaServerPage.

Now, what if instead of building all the objects from a Java ResultSet, we get references to Enterprise Java Beans using things like CustomFinderMethods?, and unlike the current way we release the database resource, why don't we keep our RemoteInterface(s) to EJB's alive so that the JavaServerPage execution is talking almost directly to the EJB server.

I digress... I'm new at this. -- KimballSampson 2001/03/28

---

Not a good idea. What you're planning is to make an enormous number of EJB calls. The problem is that EACH call into the EJB's will be its OWN transaction. (Check the EJB spec and see that it's so!). The only solution to avoid this is client-managed transactions, but that's too ugly to contemplate.

You could build a Session bean to call a bunch of Entity beans like you describe and then extract out ValueObjects (e.g., DependentObject?) but you're introducing additional layers of complexity...

Personally, I see zero (zip, zilch, nada) reasons to introduce EJB's into this simple of a problem. They provide no benefit (you don't need 2PC, you're not talking about using CMP (or are you?) and you don't need security or distribution) and will add a lot of overhead. Stick with the above solution it'll be tons faster, and simpler to boot.

KyleBrown

---

With EJB 2.0 you can use the new LocalObject? which is a lot faster that RemoteObject?. You will still have the transaction issues but depending on application server, that may or may not be a problem.

---

(Nov 05 note) Should material above be folded into a page by the name of EjbAntiPatterns?, or something similar?

It appear that the page was created in early days of EJB (because of the "With EJB 2.0...") and its contents may still serve as a warning against treating all problems like nails to the hammer tool you have.

---

CategoryEjb