Re: JDBC CTS 1.2.1 - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: JDBC CTS 1.2.1
Date
Msg-id 419A9189.3060301@opencloud.com
Whole thread Raw
In response to Re: JDBC CTS 1.2.1  (Vadim Nasardinov <vadimn@redhat.com>)
Responses Re: JDBC CTS 1.2.1
List pgsql-jdbc
Vadim Nasardinov wrote:

> The crucial difference between these two vehicles is this.  In the ejb
> vehicle, each transaction is explicitly demarcated with "BEGIN
> ... COMMIT".  When the first DROP TABLE statement fails, it causes the
> backend to ignore any subsequent statements issued in the same
> transaction.  (As a parenthetical aside, other databases don't behave
> this way.  I believe this has been discussed countless times.)

It sounds like a bug in the CTS if it assumes it can run DDL (or for
that matter any query) in a transaction after a failure. This is not
specified by JDBC, AFAIK, and is demonstrably not a valid assumption to
make under PostgreSQL.

Is there any way to tell the CTS to run each bit of DDL in a separate
transaction?

If you can issue a SAVEPOINT before the DROP TABLE and ROLLBACK TO
SAVEPOINT on failure, it might work. But it seems unlikely you can do
this without modifying the CTS itself, and you'd need to use 8.0 for
SAVEPOINT support.

It might be useful to have an option to make the driver automatically
generate SAVEPOINTs before each query (when autocommit is off), and do
ROLLBACK TO SAVEPOINT or RELEASE SAVEPOINT as appropriate after the
query completes. This gives behaviour more like other DBs at some cost
to performance (I wouldn't want it to be on by default). Again, this
would only work against an 8.0 server.

-O

pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: JDBC CTS 1.2.1
Next
From: Edoardo Ceccarelli
Date:
Subject: Websphere