|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Oliver Jowett <oliver(at)opencloud(dot)com>|
|Subject:||Re: JDBC feature request: auto savepoint per command|
|Views:||Raw Message | Whole Thread | Download mbox|
Oliver Jowett <oliver(at)opencloud(dot)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
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
|Next Message||Tom Lane||2007-04-24 00:09:30||Re: Can't build postgresql-jdbc-8.2-505 on Fedora 7|
|Previous Message||Oliver Jowett||2007-04-23 23:57:25||Re: Can't build postgresql-jdbc-8.2-505 on Fedora 7|