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
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.
In response to
pgsql-jdbc by date
|Next:||From: Oilid Adsi||Date: 2007-04-24 11:56:51|
|Subject: idle in transaction problem|
|Previous:||From: Oliver Jowett||Date: 2007-04-24 00:39:33|
|Subject: Re: Can't build postgresql-jdbc-8.2-505 on Fedora 7|