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