Re: JDBC CTS 1.2.1
От | Oliver Jowett |
---|---|
Тема | Re: JDBC CTS 1.2.1 |
Дата | |
Msg-id | 419A9189.3060301@opencloud.com обсуждение исходный текст |
Ответ на | Re: JDBC CTS 1.2.1 (Vadim Nasardinov <vadimn@redhat.com>) |
Ответы |
Re: JDBC CTS 1.2.1
|
Список | 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 по дате отправления: