Re: Couple of preparedstatement bug suspects - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: Couple of preparedstatement bug suspects
Date
Msg-id Pine.BSO.4.64.0805091532320.13570@leary.csoft.net
Whole thread Raw
In response to Re: Couple of preparedstatement bug suspects  ("Roy Smith" <roy.smith@primetext.com>)
Responses Re: Couple of preparedstatement bug suspects  (Kris Jurka <books@ejurka.com>)
List pgsql-jdbc

On Fri, 9 May 2008, Roy Smith wrote:

> No the app is not multithreaded. It's a web app and I'm the only user on my
> local test PC. So I start tomcat, run a single post which generates the
> error, stop tomcat.

Then I don't understand how it got closed mid-execution, perhaps some sort
of intermediate pooling/proxying mechanism is involved?  If you can
compose a self-contained test case, I'd be happy to look at it.

> I didn't understand your 2nd point. When I call
> PreparedStatement.executeUpdate() I have to know that the row did or did
> not get written. If there is a situation that an exception can be thrown
> after the data has been written, that exception needs to be unambiguous
> in telling the caller that the data is written or not.
>

To get this control you shouldn't be using autocommit.  You should turn
that off and then rollback if you get a SQLException.  With autocommit,
the cats already out of the bag.

Kris Jurka


pgsql-jdbc by date:

Previous
From: dombrd@gmail.com
Date:
Subject: Re: Correct getScale() behavior?
Next
From: Kris Jurka
Date:
Subject: Re: Correct getScale() behavior?