Hibernate (JPA): cómo manejar StaleObjectStateException cuando se han modificado y comprometido varios objetos

Question

Considere el escenario: una transacción DB que envía más de una fila de diferentes tablas con versiones.

Por ejemplo: una tienda y productos. Donde una lista de tiendas puede contener productos (con su cantidad en la lista de tiendas) y los productos tienen su stock actual.

Cuando inserto OU editando una lista de tiendas, quiero que el stock de esos productos en la lista de tiendas se actualice para mantener el stock constante.

Para hacer eso, abro una transacción, inserto/actualizo la lista de tiendas, actualizo las acciones para cada producto (aplicar delta) y luego confirme la transacción. No hay gran problema hasta ahora.

Sin embargo, otro usuario puede haber actualizado uno o más productos en común. O incluso actualizó la lista de tiendas en sí. En ambos casos, obtendría una STALEOBjectStateException al cometer la transacción.

La pregunta es: ¿hay alguna forma de determinar qué tabla causó la StenalObjectStateException?

En caso de que el producto causara la excepción, podría actualizar todos los productos envidiados de la DB y luego volver a aplicar los deltas de stock. Y eso está bien. En caso de que la lista de tiendas causara la excepción, sería mejor simplemente informar el problema al usuario para que pudiera comenzar de nuevo.

Muchas gracias por su ayuda.

Answer 1

Descubrí cómo.

Lo primero es lo primero: el JPA (o el Hibernate en sí) envuelve la excepción de Org.Hibernate.StaleObjectStateException como Javax.Persistence.OptimisticLockException. Entonces, si desea obtener la excepción correcta, busque OptimisticLocKException.

Segundo: El Hibernate solo arrojará el OptimisticLocKException cuando llame a la descarga del método de EntityManager antes de Commit. Si llama a Commit directamente, obtendrá otra excepción en su lugar (lo he olvidado de cuál). Teniendo en cuenta que casi todos atrapan esas excepciones emitidas por el método de confirmación y buscarán una reversión de transacción, obtendrá una excepción relacionada con la reversión (no puedo recordar cuál una vez más).

Tercero y Finaly respondiendo a mi pregunta original: solo tiene que llamar al método GetEntity desde la instancia OptimisticLockException para obtener el origen del error de versiones. Eso le proporcionará cualquier cosa que necesite relacionada con eso.

Gracias por todos los que pasaron aquí. Cualquier pregunta al respecto, solo pregunte y me alegrará ayudar.