Estoy trabajando con EJB y JPA en un servidor de aplicaciones Glassfish v3. Tengo una clase Entity en la que estoy forzando que uno de los campos sea único con una anotación @Column.¿Maneja elegantemente violaciones de restricciones en el entorno EJB/JPA?
@Entity
public class MyEntity implements Serializable {
private String uniqueName;
public MyEntity() {
}
@Column(unique = true, nullable = false)
public String getUniqueName() {
return uniqueName;
}
public void setUniqueName(String uniqueName) {
this.uniqueName = uniqueName;
}
}
Cuando trato de persistir un objeto con este campo se establece en un valor no único consigo una excepción (como se esperaba) cuando la transacción gestionada por el contenedor EJB se compromete.
que tienen dos problemas que me gustaría resolver:
1) La excepción que se ve es la inútil "javax.ejb.EJBException: transacción abortada". Si llamo recursivamente a getCause() bastantes veces, eventualmente llego a la más útil "java.sql.SQLIntegrityConstraintViolationException", pero esta excepción forma parte de la implementación de EclipseLink y no me siento cómodo confiando en su existencia.
¿Existe alguna manera mejor de obtener información detallada de error con JPA?
2) El contenedor EJB insiste en registrar este error aunque lo atrape y lo maneje.
¿Existe una forma mejor de manejar este error que evitará que Glassfish abarrote mis registros con información de excepción inútil?
Gracias.
@hallidave Mira que un 'PersistenceException' invalidará el contexto de transacciones y retrotraer la transacción, * no importa si lo detecta o no *. El javadoc dice "Todas las instancias de PersistenceException, excepto las instancias de NoResultException, NonUniqueResultException, LockTimeoutException y QueryTimeoutException, provocarán que la transacción actual, si una está activa, se marque para la reversión". Esa es una gran diferencia con JDBC simple si puedes tragar una excepción (dependiendo de lo que hagas) y aún cometer. – ewernli
@ewernli Sí, entiendo que la transacción se revierte sin importar nada; en realidad es solo el registro lleno de stacktraces que encuentro molesto. Idealmente, me gustaría capturar la excepción dentro del contexto del EJB, pero no ocurre hasta que el contenedor confirma la transacción. Estoy pensando en administrar la transacción solo para tener más control. – hallidave
¿Por qué sería mejor si EclipseLink lanzara una 'PersistenceException'? No tuvo oportunidad de descubrir qué diablos pasó (qué campo viola una restricción única (podría tener más campo único en una Entidad)) – pihentagy