Hi out there,
i´m currently working on a new portal system with ejb3.0 for persistence and logic implementation.
Writing and designing some "prototypes" i may realised some structural weakness of the EJB3.0 Spec, partly discussed (also in this forum):
The "lazy loading".
Defining relations as EAGER is in most cases very inefficient, for example if the entity is very complex with lot of relations, so in default case nearly all relations would be marked as LAZY. But this makes navigation through the database (entity bean relations) mostly impossible.
Marking Relations as EAGER is a "nice to have feature" but not really helpfull, if i (want to) write very generic interfaces in the session facade or having more compley entities with lots of relations.
Also if writing for each Business Case some additional methods with extra "value-model" classes (lot of more work) i don't want EAGER. In this case i would create a Query with "(left) join fetch entity.relation" which is more efficient.
So the logic consequence would be to tell each sessionbean method what it should load. In forum 2 options were mentioned:
1) enum Class for each Entity with an element for each relation (very dynamic and scallable) or
2) a single int which value represents a set of relations to load (not so dynamic)
In both cases i have to create the query dynamically, so it is not possible
to create generic classes (for example like EJB3DAOGeneric in Caveaemptor). The altenative to write entity.relation.size() is terrible and very unpretty in my eyes.
Strongly bounded with this problem is the transaction management.
If you think of a standard (but nohow complex) web application it has to fetch entites from database for the menutree, elements to show or the application needs (groups, permissions, ...) for processing the request. Furthermore some requests cause the logic to do changes to the database.
If one of this processes fails i want to tell the user of my webapp. If all is in one transaction which lifecycle is managed in for example a HttpFilter i get the exceptions in my filter and cannot make any notfies to the user.
If i make transaction-per-facade-method i have the problem i cannot lazy fetch entities. This is a big problem if someone uses something like Struts with MVC 2+1 (Actions create context/content for jsp/template which only renders given content), to keep away too much logic from jsps.
It is nice to have all this tutorials, but most of them are very basic and do not satisfy requirements for productive use of ejb3.0. So is there any fully implemented application (no tutorials, test, howtos, .. )
which is productive in use or some "extended" tutorials?
Perhaps i am completly wrong, but what i conceived until now doesn't satisfy or makes me happy. So perhaps someone has a position/statement to all this?
Why not just have use cased base DAO methods.
Order getOrderSummary(...) //order with no line items but maybe a calc field of how many lis there are? maybe customer/shipping info...
Order getOrderDetails(...) //order with line items
Passing other stuff moves your data layer up. This keeps it to where you merely ask for what you want and get it.
However, I'm a mere hacker and not an architect :-)
ok... that´s a option for a single application. But if you think
in context of portals where you want to make interfaces accessable to
portlets or modules where don´t even know the requirements
this is not flexibe enough.
One opinion would be to do without relations and only work with the relationkeys like liferay. But this is also very inefficient.
Ok.. back to my question about a productive application using ejb3. Is there any?
Have a look at JBoss Seam and how it handles EntityManager lifecycle
thx for this hint.. is there any doucmentation about how seam handles EntityManager lifecycle or "use the force use the source"?
or can perhaps someone explain in a few sentences how the handels it?
ok, what i read is really nice. They throw the complete logic in sessionbeans and let act them as componets for jsf (like actions is struts) and solve the transation/lazy-fetching with different contexts and with something like an action phase and render phase (like portlets with processAction and render).
Do you think it would be possible to create such a modular behaviour like portals with seam? Also you would have now more than a single war file for your module (some sessionbeans).