Thread: PostgreSQL JDBC + Hibernate lose valuable debug info if an exception is thrown

Hi,

When using Hibernate together with PostgreSQL the following might happen:

- Hibernate uses batched updates
- An exception is thrown (e.g. when a foreign key constraint is violated or
a not null column is left out, etc.)
- This SQLException is wrapped in a PBatchUpdateException
- This PBatchUpdateException is wrapped in a HibernateException
- The HibernateException is written to the log

The problem is that Hibernate uses standard stacktrace print routines with
Root causes as found in JDK 1.4. The call on getNextException() as found in
SQLException is never made and valuable debugging information is lost, e.g.
the actual cause of the BatchUpdateException.

I am wondering whether it is possible to mimic JDK 1.4 root cause exception
handling in PBatchUpdateException so a decent stack trace can be logged.

Hope that this request makes any sense,

Regards,


Jeroen

* Vianen, Jeroen van (jeroen.van.vianen@satama.com) wrote:
> I am wondering whether it is possible to mimic JDK 1.4 root cause exception
> handling in PBatchUpdateException so a decent stack trace can be logged.

As a workaround put:
hibernate.jdbc.batch_size = 0
in your hibernate.properties file.

I believe this will disable Hibernate use of batching, and you will get
a "nicer" stack trace.


Hope this help,
Anders

Vianen, Jeroen van wrote:
> Hi,
>
> When using Hibernate together with PostgreSQL the following might happen:
>
> - Hibernate uses batched updates
> - An exception is thrown (e.g. when a foreign key constraint is violated or
> a not null column is left out, etc.)
> - This SQLException is wrapped in a PBatchUpdateException
> - This PBatchUpdateException is wrapped in a HibernateException
> - The HibernateException is written to the log
>
> The problem is that Hibernate uses standard stacktrace print routines with
> Root causes as found in JDK 1.4. The call on getNextException() as found in
> SQLException is never made and valuable debugging information is lost, e.g.
> the actual cause of the BatchUpdateException.
>
> I am wondering whether it is possible to mimic JDK 1.4 root cause exception
> handling in PBatchUpdateException so a decent stack trace can be logged.

It's not instantly clear how this should be structured. There might be
multiple SQL exceptions generated, but they are not necessarily causes
of each other.

How about something like:

   PBE instanceof PBatchUpdateException
   PBE.getNextException() == E1
   PBE.getCause() == E1

   E1 instanceof SQLException
   E1.getNextException() == E2
   E1.getCause() == null (or actual cause of E1)

   E2 instanceof SQLException
   E2.getNextException() == E3
   E2.getCause() == null (or actual cause of E2)

   ... etc ...

i.e. you don't get all exceptions chained via 1.4-style getCause(), but
the BatchUpdateException's cause points to the first exception in the
chain of actual exceptions. pre-1.4 clients can still get access to the
underlying exception from the BatchUpdateException by walking the SQL
exception chain as usual.

Note that if Hibernate isn't walking the exception chain, you may be
losing information anyway even when batch exceptions are not involved --
if there is more than one exception generated they are not linked via
the 1.4 mechanism (deliberately, as each exception in the chain might
have an independent cause such as an IOException). So Hibernate probably
needs fixing too :)

-O