In previous versions, all entity beans were considered coarse-grained persistent objects, requiring every access to the bean to be completed over an RMI invocation. For example, a customer profile might be considered a coarse-grained object, but the credit card information stored for a single customer profile might be too fine to warrant having RMI invocations and separate transaction management as part of the object's access logic. If two objects are both considered remote, the persistence manager will ultimately have to perform separate database updates to manage both of the objects. Dependent objects are not entity EJBs and have a JavaBean-like syntax. This can occur if a parent object is destroyed and the deployment descriptor is configured not to perform cascading deletions of any child-dependent objects.
Life cycle objects that follow the same life cycle of a parent object.
A life cycle object is created when its parent is created and destroyed when its parent is destroyed. The child object is preferably created and destroyed automatically by the parent's container or persistence manager. This is particularly useful for modeling composition UML relationships where a child object cannot exist without its parent object. In the earlier example, if credit card information is only ever associated with a customer profile, the credit card information may be modeled as a life cycle object where the life of the credit card is managed automatically by the persistence manager of the customer profile object. Dependent objects have a cascading delete deployment descriptor option that instructs a container to manage the destruction of dependent objects attached to parent objects.