JPA: OptimisticLockException y en cascada

En mi proyecto actual, utilizo Spring Data JPA con Hibernate, pero considero esto como una pregunta más general que también debe cubrir JPA "simple".

No estoy seguro de cómo debo tratarOptimisticLockException cuando usas@Version.

Debido a cómo funciona mi aplicación algunas relaciones tienenCascadeType.PERSIST yCascadeType.REFRESH, otros también tienenCascadeType.MERGE.

Donde manejarOptimisticLockException

Por lo que sé, el manejo de esto en la capa de servicio no funcionará especialmente conCascadeType.MERGE porque entonces la entidad infractora podría ser una que deba ser manejada por otro servicio (tengo un servicio por clase de entidad).

El problema es que estoy creando un marco y, por lo tanto, no hay ninguna capa por encima del servicio, así que simplemente podría "delegar" esto al usuario de mi marco, pero eso parece "débil y perezoso".

Determine la entidad infractora y los campos que cambiaron

Si se produce una excepción OptimisticLockException, ¿cómo obtengo qué entidad causó el problema y qué campos se cambiaron?

Si puedo llamargetEntity() pero ¿cómo puedo convertir eso en el Tipo correcto, especialmente si se utilizó CascadeType.MERGE? La entidad podría ser de varios tipos, por lo que un if / switch coninstanceof viene a la mente pero esto parece feo como el infierno.

Una vez que tenga el tipo correcto, necesitaría obtener todas las diferencias entre las versiones, excluyendo ciertos campos como la versión en sí o la última fecha de modificación.

En el fondo de mi mente también está HTTP 409, que indica que en caso de conflicto, la respuesta debe contener los campos en conflicto.

¿Hay un "patrón de mejores prácticas" para todo esto?

Respuestas a la pregunta(2)

Su respuesta a la pregunta