Re: Couple of preparedstatement bug suspects

From: Kris Jurka <books(at)ejurka(dot)com>
To: Roy Smith <roy(dot)smith(at)primetext(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Couple of preparedstatement bug suspects
Date: 2008-05-09 19:36:02
Message-ID: Pine.BSO.4.64.0805091532320.13570@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2008-05-09 19:45:24 Re: Correct getScale() behavior?
Previous Message dombrd 2008-05-09 19:28:12 Re: Correct getScale() behavior?