Re: JDBC feature request: auto savepoint per command
От | Tom Lane |
---|---|
Тема | Re: JDBC feature request: auto savepoint per command |
Дата | |
Msg-id | 17424.1177373126@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: JDBC feature request: auto savepoint per command (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: JDBC feature request: auto savepoint per command
Re: JDBC feature request: auto savepoint per command |
Список | pgsql-jdbc |
Oliver Jowett <oliver@opencloud.com> writes: > They seem to be confusing rollback and commit of the managed transaction > with use of savepoints.. I don't see why the prohibition on messing with > the top-level global transaction affects use of savepoints, since use of > savepoints won't affect that top-level transaction? I got some further comments later in the day, which might mean more to you than they do to me: > In this particular case, the client wants the best of both worlds. > They are using straight JDBC, but they also want to use CMT. In > essence they want to execute JDBC interactions in a non-atomic manner > only committing the *global* transaction on completion. While Oracle, > DB2 etc support this, the savepoint commit()/rollback() issue with > the PG driver makes this all but impossible given the current code > base. Effectively the underlying JDBC transaction gets terminated on > statement failure requiring an explicit savepoint and rollback to > return the connection to a usable state which again, when using CMT > is not valid because the connection is still enlisted within a global > transaction. I'm honestly not sure how much of this is "it really would violate some spec or other" versus "we don't feel like putting in a special case". But the bottom line is they'd like us to act like all the other databases they support on this point. regards, tom lane
В списке pgsql-jdbc по дате отправления: