From: | "Adrian Geissel" <ageissel(at)zenark(dot)com> |
---|---|
To: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | [JDBC driver] DBConstraint violation within transaction block leaves connection in indeterminate state |
Date: | 2001-11-21 15:21:19 |
Message-ID: | 052a01c172a0c4c0d40a0078c1@zenark.ie |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
I'm running Postgresql 7.1.2 server on RedHat Linux 7.1 (intel) and connecting using JDBC on Windows NT using jdbc7.1-1.2.jar.
The sequence to reproduce the error is as follows:
1. Create database with various constraints (such as UNIQUE, CHECK, etc).
2. Queue 3 or more INSERT / UPDATE statements on a connection with AutoCommit turned off.
3. Let the second statement violate a structural constraint (as specified in 1. above)
4. Commit the transaction
5. Now issue any database query statement against the same connection.
==BUG: the query that is executed is the third queued statemenet, which does not return any results
To work-around this, trap the SQLException that is thrown within the transaction block and call connection.rollback().
My understanding in relation to transaction blocks is that if the transaction fails, then the database is not updated. Furthermore, I would also expect that the connection is left in an equally clean state, but this clearly is not the case. If the transaction fails, then surely all statements queued should be considered expired, and let the caller re-queue them as part of error recovery.
Please clarify whether my expected behaviour is correct, and if this is a bug, then it needs to be addressed.
Many thanks
Adrian Geissel
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-11-21 20:27:21 | Bug #518: SERIAL type value not seen in FOREIGN KEY |
Previous Message | Darcy Buskermolen | 2001-11-20 17:07:39 | Re: Bug #517: TO_CHAR(timestamp, 'Day') adds extra |