RE: JDBC Drop/Create problem?

I'm not sure if the term's "aborted" (been a horrible week, etc), but as the
drop failed, any transaction its contained within must also fail - thats the
point of transactions. If it didn't then you could find complex
relationships breaking down all over the place.

What would be nice would be nested transactions. Then the drop could be
placed within its own transaction, and the outer one wouldn't be affected.

Peter

--
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: Greg Speegle [mailto:Greg(at)10happythings(dot)com]
> Sent: Thursday, December 07, 2000 6:19 PM
> To: Peter Mount
> Cc: pgsql-interfaces(at)postgresql(dot)org
> Subject: Re: [INTERFACES] JDBC Drop/Create problem?
>
>
>
> Ah. That explains it. Thanks.
>
> Out of curiosity, why does the transaction get marked as aborted? I
> only ask since others
> (e.g. Oracle) don't have this behavior.
>
> Greg
>
> Peter Mount wrote:
>
> > Dropping a non-existent table should throw an exception as
> well as mark any
> > open transaction as aborted.
> >
> > I'd say either:
> >
> > * using autoCommit while checking for existing tables.
> > * commit and begin a new transaction afterwards.
> > * Use temporary tables, so the table doesn't survive the connection.
> >
> > Peter
> >
>

Today, in a message to Greg Speegle, Peter Mount wrote:
>
> I'm not sure if the term's "aborted" (been a horrible week, etc), but
> as the drop failed, any transaction its contained within must also
> fail - thats the point of transactions.

Well no, that is not necessarily the point of transactions. It is
sufficient to report the error and the calling process can decide whether
to continue the transaction using another approach or to abort it by
calling rollback. The RDBMS should abort a transaction only when it has no
reasonable way to revert to the state before the command that failed.

All major RDBMS systems behave this way, hence one cannot be surprised
when people expect this behaviour also in Postgresql. This was discussed
here several times.

> What would be nice would be nested transactions. Then the drop could
> be placed within its own transaction, and the outer one wouldn't be
> affected.

Nested transactions are more general than statement-level abort in that
they allow users to define the scope of the nested transaction. It is also
the preferred way to cleanly implement statement-level abort.

Joachim

--
work: joachima(at)realtimeint(dot)com (http://www.realtimeint.com)
private: joachim(at)kraut(dot)ca (http://www.kraut.ca)