Re: Weird behavior in transaction handling (Possible bug ?)
От | Oliver Jowett |
---|---|
Тема | Re: Weird behavior in transaction handling (Possible bug ?) |
Дата | |
Msg-id | 41E8C5F1.1030800@opencloud.com обсуждение исходный текст |
Ответ на | Re: Weird behavior in transaction handling (Possible bug ?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: