I found another way to run the two scenarios suggested in your comments. Instead of using JPA, an alternative CustomerDAO implementation uses plain JDBC.

For scenario 1), the jdbc implementation simply performs the update within a transaction. When the update fails, an exception is raised which traces back to the cause: see jdbc_stacktrace.txt

For scenario 2), the CustomerDAO implementation:

1. starts a transaction
2. registers a synchronization
3. attempts to commit
4. the synchronisation marks the transaction for rollback only

The exception raised nevertheless still traces back to the cause: see jdbc_mark_rollback_only_stacktrace.txt

Please let me know if anything is not clear.