Hibernate and deleting persistent objects:
When deleting objects with Hibernate it's best to think of it as making an object transient. The state of the object is erased from the database but it can be referenced.  The order of deleting the objects is not important because there is no risk of violating a foreign key constraint. A NOT NULL constraint on a foreign key column may still be violated if the order is incorrect.--
This is resolved by cascade options.
When flushing the session, the following order is important
All entity insertions in the same order that the save () were called
All entity updates
All collection deletions
All collection elements deletions, updates and insertions.
All collection insertions
All entity deletions in the same order as delete () were called.
While this order is guaranteed there are no guarantees when these JDBC calls will be called except unless explicitly invoked with a flush(). That said, there are different FlushModes available to make these less frequent.
These modes include :
- flush at commit time when the Hibernate Transaction API is used
- flush automatically using the explained routine
- or never flush unless flush is explicitly called.
In addition to Flush modes and cascade styles offered, Hibernate also makes its metadata available to applications. This way applications can choose to implement deep copy algorithms such as for mutable value types and not for immutables or associated entities. Hibernate exposes metadata via the SessionFactory. Instances of the metadata interfaces include ClassMetadata, CollectionMetadata, and the Type hierarchy.