Tom Lane schrieb:
> 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.
Is it possible that they don't really understand that this is not about
the JDBC driver at all, but just the way PostgreSQL works, no? So a
driver option to do automatic save-pointing is the _only_ way to get the
behavious they want, I guess. (Other than invasive backend hacking)
> 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.
If you look at the list archives, there were a number of people who did
not expect this PostgreSQL-specific behavior (transaction rollback on
statement error). I guess there will be many happy people if someone
implements implicit savepoints in the JDBC driver.
Best Regards
Michael Paesold
