How can I handle/recover a DB Integrity constraint violation exceptions in hibernate?

I'm developing a big web application that uses JSF and hibernate as its ORM. My hibernate sessions are long (the user can do big amount of modifications on the screen and the changes will only be persistent on DB when he'll press the save button) I'm recently struggling with an issue of roll-back / cancellation of user modification and looking for different solutions and approaches.

I want to recover from a violation constraint exception ("ORA-02292: integrity constraint").

Consider the following scenario:
there is a table 'X' with a record 'x' and a table 'Y' with a record 'y' - where 'x' Depends on 'y' by a foreign key. The user is trying to delete record 'y' and although there is a future possible integrity constraint violation on this step, I'm not throwing any exception because the user is able to fix it later and only if he won't fix it and try to save the screen the DB will throw an exception which will be aggregated to the user interface.

I can't find a good way to recover from this violation.
In the save process, after trying to delete record 'y', DB launches the "ORA-02292: integrity constraint" exception as expected.
My problem is that if such an error occurred and the user did fixed the foreign key constraint by selecting another record instead of 'y', hibernate won't recognize it because AFAIK it will still first try to remove 'y' (because of the action queue) and fail before it comes to the action that replaces 'y' with another entity.
So what's going on is that the DB keeps firing exceptions while trying to save changes and I can't find a way to fix it without refreshing the entire screen (which means that the new hibernate session loosing all of the user new data). it seems like the action queue saves the delete action and won't clear it even if Session "evict" or "clear" methods are called.

I am aware that I could validate changes before committing them and that it might work but I'm not interested in this kind of solution because: 1. validate a large amount of possible changes can cause a performance issue, furthermore I believe that oracle DB can do it for me much better. 2. I don't want to enforce the user to a specific order of actions.