Re: Unable to commit: transaction marked for rollback

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "David Kerr" <dmk(at)mr-paradox(dot)net>
Cc: <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Unable to commit: transaction marked for rollback
Date: 2010-07-01 19:20:08
Message-ID: 4C2CA4180200002500032F32@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

David Kerr <dmk(at)mr-paradox(dot)net> wrote:

> Would postgres normally log the error in the TX?

A previous statement should have generated the original exception,
if that's what you mean.

> (it's not, which is why i'm asking)

Where are you checking? If you're talking about exceptions you're
fielding, it wouldn't be the first time I've seen sloppy exception
handling hide the first exception (the one that actually matters)
and throw a secondary exception. One common mistake is to catch the
first exception and try to do some cleanup, but allow an exception
to be thrown from the cleanup code -- completely hiding the first
exception.

The general pattern I follow to prevent such problems is:

ResourceX rx = null;
ResourceY ry = null;
try
{
rx = new ResourceX();
ry = rx.createY();
<use resources>
ry.close();
ry = null;
rx.close();
rx = null;
}
finally
{
if (ry != null)
{
try
{
ry.close();
}
catch (Exception e2)
{
// ignore
}
ry = null;
}
if (rx != null)
{
try
{
rx.close();
}
catch (Exception e2)
{
// ignore
}
rx = null;
}
}

There are, of course, variations on this, but you get the gist of
it.

Have you checked the PostgreSQL log file for clues? If you're not
seeing what you need, you could tweak the logging to show more.

-Kevin

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message David Kerr 2010-07-01 20:43:13 Re: Unable to commit: transaction marked for rollback
Previous Message David Kerr 2010-07-01 18:57:55 Re: Unable to commit: transaction marked for rollback