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
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 |