Cascade settings are unidirectional. This means that it must be explicitly set on both sides
of a relationship if the same behavior is intended for both situations

In the Persisting an Entity section, we mentioned that the entity instance is ignored if it is
already persisted. This is true, but the entity manager will still honor the PERSIST cascade in this
situation.

There are really only two
cases where cascading the remove() operation makes sense: one-to-one and one-to-many relationships
where there is a clear parent-child relationship.

Occasionally it may be necessary to clear a persistence context of its managed entities. This is
usually required only for application-managed and extended persistence contexts that are
long-lived and have grown too large in size.

All entity
instances managed by the persistence context become detached with their state left exactly as
it was when the clear() operation was invoked.

That said, a flush of the persistence context could occur at any time if the persistence
provider deems it necessary. An example of this is when a query is about to be executed and it
depends on new or changed entities in the persistence context. Some providers will flush the
persistence context to ensure that the query incorporates all pending changes. A provider
might also flush the persistence context often if it uses an eager-write approach to entity updates.
Most persistence providers defer SQL generation to the last possible moment for performance
reasons, but this is not guaranteed.

Any time a detached object that is the target of the one-to-one or many-to-one
relationship is encountered where the source entity is the owner, the flush will still proceed
because the act of persisting the owning entity does not depend on the target. The owning entity
has the foreign key column and needs to store only the primary key value of the target entity.

There are two views on detachment. On one hand, it is a powerful tool that can be leveraged by
applications in order to work with remote applications or to support access to entity data long
after a transaction has ended. On the other hand, it can be a frustrating problem when the
domain model contains lots of lazy-loading attributes and clients using the detached entities
need to access this information.

• When the transaction that a transaction-scoped persistence context is associated with
commits, all of the entities managed by the persistence context become detached.
• If an application-managed persistence context is closed, all of its managed entities
become detached.
• If a stateful session bean with an extended persistence context is removed, all of its
managed entities become detached.
• If the clear() method of an entity manager is used, it detaches all of the entities in the
persistence context managed by that entity manager.
• When transaction rollback occurs, it causes all entities in all persistence contexts associated
with the transaction to become detached.
• When an entity is serialized, the serialized form of the entity is detached from its
persistence context.

The argument to merge() does not become managed
as a result of the merge. A different managed entity (either a new instance or an existing managed
version already in the persistence context) is updated to match the argument, and then this
instance is returned from the merge() method.