A service I work on uses the JDBC API to update an Oracle database. One of the methods that updates the database has autocommit set to false in order to execute 2 SQL statements. But even though autocommit is set to false the first SQL statement gets executed and we receive a integrity constraint violation error.
java.sql.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (V500.XFK3) violated - child record found
Shouldn't disabling autocommit wait for the commit method to be called? If not how can both queries be executed?
On tables that have the constraint disabled the above error doesn't show up and the queries are executed.
Constraints are evaluate on the operation - not the commit of the operation. What you need to do is either deal with deferred constraints, or do the operations in the correct order to avoid foreign key violations. Insert the parent and then do the child.
for a brief intro to deferrable constraints and some subtle issues with using them, start here
I would strongly suggest, however, that the parent-child relationship constraints in the database were probably created for good reason - so disabling the constraints is a bad idea that will lead to bad data. And deferable constraints should be used as seldom as possible. You may think its a pain to have to figure out the correct order of operations to satisfy constraints, but its the right way to go if you are having the UI do direct DML. To be honest, I'm a far bigger fan of having PL/SQL APIs exposed to the outside world with the table details hidden for a variety of security and maintenance reasons. The UI should just be saying "store this data entity" and the interface knows how to put it all in the correct tables. That way the back end can be redesigned for efficiency without the front end needing to be aware of it.