Re: JDBC CTS 1.2.1

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Vadim Nasardinov <vadimn(at)redhat(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC CTS 1.2.1
Date: 2004-11-16 23:47:21
Message-ID: 419A9189.3060301@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2004-11-17 00:00:31 Re: Why is PGStream.flush() taking so much time?
Previous Message Edoardo Ceccarelli 2004-11-16 23:31:18 Websphere