From: | Peter Mount <petermount(at)maidstone(dot)gov(dot)uk> |
---|---|
To: | "'pgsql-interfaces(at)postgresql(dot)org'" <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | RE: JDBC Drop/Create problem? |
Date: | 2000-12-12 09:13:20 |
Message-ID: | 1B3D5E532D18D311861A00600865478CF1B64E@exchange1.nt.maidstone.gov.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
--
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: petermount(at)maidstone(dot)gov(dot)uk
WWW: http://www.maidstone.gov.uk
All views expressed within this email are not the views of Maidstone Borough
Council
> -----Original Message-----
> From: Joachim Achtzehnter [mailto:joachim(at)kraut(dot)ca]
> Sent: Monday, December 11, 2000 5:29 PM
> To: pgsql-interfaces(at)postgresql(dot)org
> Subject: RE: [INTERFACES] JDBC Drop/Create problem?
>
>
> Today, in a message to pgsql-interfaces, Peter Mount wrote:
> >
> > The problem JDBC has is that it's DatabaseMetaData methods can make
> > several queries. While AutoCommit is off, if one of those fails, the
> > users transaction will also fail.
>
> If the JDBC driver under the hood performs several queries in
> response to
> a single 'user command' and one of these fails it can still
> report that
> command's failure without aborting the whole transaction (assuming the
> backend supports statement-level aborts, of course).
Unless 7.1 now supports statement level aborts (and it's possible I've
missed it if it has) this is where the problem lies. The backend currently
does abort the whole transaction.
Peter
From | Date | Subject | |
---|---|---|---|
Next Message | Sylvain Barrette | 2000-12-12 14:37:27 | RE: Error connecting to database |
Previous Message | Peter Mount | 2000-12-12 09:10:21 | RE: RE: JDBC Timestamp Problem |