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
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 |