Re: - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re:
Date
Msg-id 1036532475.27825.7.camel@inspiron.cramers
Whole thread Raw
In response to Re:  (Karl Goldstein <karlgold@yahoo.com>)
List pgsql-jdbc
Karl,

This behaviour isn't an artifact of the driver, but of the server. As I
mentioned earlier the driver doesn't even know it is in a transaction.

Dave

On Tue, 2002-11-05 at 16:35, Karl Goldstein wrote:
> Barry,
>
> I've primarily been using the 7.2 driver.  I'm pretty sure I tried the latest driver as well, and
> got the same error message.
>
> In any event, now that the expected behavior is clear to me I can carry on with my app.  I would
> suggest, however, adding a note about this behavior to the JDBC documentation [1], since it does
> differ from the way the Oracle JDBC driver behaves, for example.
>
> Karl
>
> [1] http://candle.pha.pa.us/main/writings/pgsql/sgml/jdbc.html
>
> --- Barry Lind <blind@xythos.com> wrote:
> > Karl,
> >
> > What version of the driver are you using?  I think the error reported in
> > this case in the latest version (7.3) is better than the error from the
> > 7.2 driver.
> >
> > --Barry
> >
> > Karl Goldstein wrote:
> > > I don't have a strong opinion either way.  For me, the main problem with the current behavior
> > is
> > > simply that the error message is confusing.  If it is indeed the case that any SQLException
> > > invalidates the current transaction (and my impression is that this is not intended), then the
> > > driver should report that directly and not even let you try to execute later statements.  The
> > "No
> > > results were returned by the query" error just left me scratching my head.
> > >
> > > Thanks,
> > >
> > > Karl
> > >
> > > --- Daniel Serodio <daniel@checkforte.com.br> wrote:
> > >
> > >>I've never worked with Oracle, just MySQL and PostgreSQL, but isn't this
> > >>the definition of a transaction?
> > >>
> > >>"A transaction is an atomic unit of processing; it is eigher performed
> > >>in its entirety or not at all"
> > >>
> > >>My understanding of this is that if one statement failed, all of the
> > >>following statements should fail.
> > >>
> > >>On Tue, 2002-11-05 at 14:31, Csaba Nagy wrote:
> > >>
> > >>>Hi all,
> > >>>
> > >>>I was wondering if there's any chance of this behavior to change in the
> > >>>future ?
> > >>>I mean will it be possible to continue a transaction after one of the SQLs
> > >>>failed, by only rolling back what that query did ?
> > >>>In many real life applications recovery is very possible after a failed
> > >>>query, and (the not failed part of) the transaction should be committed.
> > >>>This is one of the big differences in behavior between Postgres and Oracle,
> > >>>making life hard for porting...
> > >>>
> > >>>Cheers,
> > >>>Csaba.
> > >>
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > HotJobs - Search new jobs daily now
> > > http://hotjobs.yahoo.com/
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> > >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
>
>
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Dave Cramer <Dave@micro-automation.net>


pgsql-jdbc by date:

Previous
From: Karl Goldstein
Date:
Subject: Re:
Next
From: Tom Lane
Date:
Subject: Re: