Implementing POJOs with EJB 3 - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 370

is essential for relationships such as PendingOrder - PendingOrderLineItem , where
line items must be deleted when they are no longer associated with the parent.
To correctly implement these kinds of a relationship, a portable EJB 3 applica-
tion must contain code to explicitly delete orphaned children. For example, the
method PendingOrder.updateQuantities() , which updates the lineItems field,
must call EntityManager.remove() on each line item it removes from the
lineItems fields. This potentially impacts several classes in the domain model.
First, we have to encapsulate the deletion code in a repository such as the
PendingOrderRepository . Second, we must change the PlaceOrderService to pass
the repository to the PendingOrder . Finally, we need to change the PendingOrder
to call the repositories. Lots of little changes—all because EJB 3 lacks a feature
that has been in JDO and Hibernate for quite some time.
The alternative, of course, is to use a vendor-specific feature. For example,
JBoss EJB 3 supports a nonstandard @Cascade annotation that lets you tell the EJB 3
implementation to delete orphaned children:

public class PendingOrder implements Serializable {
…
@OneToMany(cascade = { CascadeType.ALL })
@OrderBy("index")
@JoinColumn(name = "PENDING_ORDER_ID")
@org.hibernate.annotations.Cascade(org.hibernate.annotations.
bbbbbbbbbbbbbbbbbbbbbbbbbbbbb b ➥ CascadeType.DELETE_ORPHAN)

private List<PendingOrderLineItem> lineItems = new
ArrayList<PendingOrderLineItem>();

…
}
The value of CascadeType.DELETE_ORPHAN specifies that the EJB container should
delete children when they are removed from the collection.
As you can see, these kinds of limitations force you to make the difficult deci-
sion between writing a portable application that requires extra code and using
vendor-specific extensions. I hope these problems are addressed before the
release of the EJB 3 specification. After all, it's not as if there is anything new to
invent or discover.

Limitations of fetch joins
EJB 3' s support for eager loading is definitely an improvement over EJB 2 , which lacks
a mechanism for configuring eager loading and requires you to use a vendor-specific
mechanism. EJB 3 lets you statically configure eager loading in the annotations
defining the O/R mapping or dynamically by using Hibernate-style fetch joins in