Identificación de Excepciones SQL

Cuando el log del servidor de aplicaciones lanza un error de este tipo:


... Caused by: com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -407, SQLSTATE: 23502, SQLERRMC: TBSPACEID=3, TABLEID=27, COLNO=2

nos gustaría saber a qué tabla y columna específica se refiere este error. Existen dos tablas que contienen esta información:

SYSCAT.TABLES y SYSCAT.COLUMNS

Para el ejemplo anterior, las sentencias que nos entregan la información deseada son:

SELECT TABNAME FROM SYSCAT.TABLES WHERE TABLEID=27 AND TBSPACEID=3;

y luego:

SELECT * FROM SYSCAT.COLUMNS WHERE COLNO = 2 AND TABNAME = [TABNAME];

donde [TABNAME] es el nombre de la tabla, que dio resultado la primera consulta.

Manejo de Excepciones en EJB 3

¿Debiera una transacción retrotraerse cuando se lanza una excepción y ésta no se captura? En EJB 2, sólo se retrotrae automáticamente la transacción en el caso de excepciones no chequeadas (subclases de RuntimeException). Para lograr el mismo resultado con excepciones chequeadas, era necesario capturar dichas excepciones, marcar manualmente la transacción como "fallida" y luego relanzar la excepción:


        } catch (AccessDeniedException e) {
            getSessionContext().setRollbackOnly();
            throw e;
        }
        ...

En EJB 3, esto ya no es necesario, ya que existe la posibilidad de definir esto en la misma excepción:

        @ApplicationException(rollback=true)
        public class ServiceException extends Exception {...

de esta manera, el contenedor EJB sabe que, de lanzarse este tipo de excepciones y no ser capturadas, la transacción activa debe retrotraerse.

Más información:

http://today.java.net/article/2006/04/04/exception-handling-antipatterns

Bienvenida

Este es mi primer posteo, espero publicar información útil y una que otra opinión.