You call EntityManager.remove(entity) on a managed entity inside a transaction. What state is that instance in afterwards, when does the DELETE statement actually reach the database, and what happens if you call persist() on the same instance before the transaction commits?

## remove() is a scheduling call, not a SQL call Hibernate batches work. `EntityManager.remove(entity)` marks a managed instance as **removed** and appends a delete action to the session's action queue. The instance stays in the persistence context — you can still read its fields, and it still occupies its slot in the identity map — but Hibernate now intends to delete its row. The SQL DELETE is issued at the next **flush**, which happens in three ways: you call `flush()` yourself; you run a query and the flush mode causes Hibernate to synchronise first so the query sees your pending work; or the transaction commits. This deferral is what allows Hibernate to order statements sensibly (inserts before updates before deletes within its own ordering rules) and to batch them. ## What you may and may not do to a removed instance JPA specifies the behaviour of each operation against a removed instance: - `persist(removedInstance)` — **cancels the removal**. The instance goes back to managed and no DELETE is executed. This is the one genuine "undo", and it only works before the delete has been flushed. - `remove(removedInstance)` — ignored, it is already scheduled. - `merge(removedInstance)` — an `IllegalArgumentException`. - `refresh(removedInstance)` — an `IllegalArgumentException`. - `detach(removedInstance)` — the instance leaves the context; the pending delete is not cascaded further. Modifying fields of a removed entity is pointless: dirty checking will not produce an UPDATE for a row that is about to disappear (Hibernate will not emit an UPDATE followed by a DELETE for the same instance in the ordinary case). ## Removing something the context doesn't manage - **Transient instance**: `remove()` is defined as ignored. Nothing was ever persisted, so there is nothing to delete. - **Detached instance**: `remove()` throws `IllegalArgumentException` — or, depending on the provider and timing, the transaction fails at commit. The persistence context has no idea whether that instance's data is current, so it refuses. The correct pattern is `em.remove(em.find(Order.class, id))`, or `em.remove(em.merge(detached))` when you already hold the object. `find()` is preferable: it avoids copying a possibly stale object's state into the context just to delete it. ## Cascades and orphan removal `cascade = CascadeType.REMOVE` propagates the removed state to associated entities at the time of the call, so children are queued for deletion too. `orphanRemoval = true` is different in trigger: removing a child from the parent's collection makes Hibernate schedule a delete for that child at flush, even though you never called `remove()` on it. Both end at the same state. Note that a bulk `DELETE` in JPQL bypasses all of this — it does not consult or update the persistence context, so instances already loaded stay managed and stale, and cascades are not applied. ## Order of statements at flush Hibernate's default flush ordering executes inserts, then updates, then collection operations, then deletes. That is a frequent source of constraint violations in the delete-then-insert-same-key pattern: within a single flush, deleting a row and inserting another with the same unique key can fail because the INSERT is executed *first*. The remedy is an explicit `flush()` between the two operations, which forces the delete out to the database before the insert is queued. ## After the delete Once the DELETE has run and the transaction commits, no row corresponds to the object anymore. The instance is no longer managed and is effectively an ordinary object again. If you call `persist()` on it now, with a generated identifier Hibernate will assign a new one and INSERT a new row; with an assigned identifier it will INSERT under the old key. Either way it is a fresh row, not a resurrection — anything that referenced the old row by id is not repaired. ## Practical checklist - Deleting inside a loop and expecting each DELETE immediately? Add `flush()` (and `clear()`) periodically, or the action queue grows. - Deleted rows still visible to a query in the same transaction? Your flush mode or the query type is skipping the flush — force it. - `IllegalArgumentException: Removing a detached instance`? Load it first inside the transaction. - Constraint violation on a delete-then-recreate? Flush between the two.