Tom Lane wrote:
> Vadim Nasardinov <vadimn@redhat.com> writes:
>
>>On Friday 14 January 2005 16:38, Oliver Jowett wrote:
>>
>>>It might be worthwhile having commit() throw an exception if the
>>>transaction did not actually commit, rather than only reporting
>>>server-generated errors. What do people think?
>
>
>>Sounds like a good idea.
>
>
> Doesn't the JDBC spec have anything to say about what this should do?
The JDBC spec is vague as usual.
The Connection.commit() javadoc says:
===
Makes all changes made since the previous commit/rollback permanent
and releases any database locks currently held by this Connection
object. This method should be used only when auto-commit mode has been
disabled.
Throws:
SQLException - if a database access error occurs or this
Connection object is in auto-commit mode
===
What counts as a "database access error"? We currently throw on
communication errors or server-generated errors only. A previous error
causing transaction rollback doesn't seem like an access error really,
but given that you can get other errors thrown when the transaction does
not commit for other reasons, I'm not sure why that case should be
different.
-O
