[
https://issues.apache.org/jira/browse/DERBY-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6670:
---------------------------------
Attachment: derby-6670-01-aa-forbidSavepointsWithDeferredConstraints.diff
Attaching derby-6670-01-aa-forbidSavepointsWithDeferredConstraints.diff. This
patch prevents you from creating an explicit savepoint or calling a database
procedure while work involving a deferred constraint is in-flight. I am running
tests now.
This is a meat-ax approach to the problem. This is a temporary fix intended for
10.11.1. If this approach seems reasonable, I will log a follow-on issue so
that Dag can back out this patch and solve the problem correctly after he
returns from vacation. The correct fix could go into a later 10.11.2
maintenance release.
Touches the following files:
-----------------
M
java/engine/org/apache/derby/iapi/sql/conn/LanguageConnectionContext.java
M
java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
Add an LCC entry point to check whether it's safe to create a savepoint or call
a dbproc.
-----------------
M
java/engine/org/apache/derby/impl/sql/execute/CallStatementResultSet.java
M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java
Invoke that new method when trying to explicitly manipulate a savepoint or call
a dbproc.
-----------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/PrimaryKeyTest.java
Verification that Knut's original repro is addressed as well as the dbproc case.
> Rollback to savepoint allows violation of deferrable constraints
> ----------------------------------------------------------------
>
> Key: DERBY-6670
> URL: https://issues.apache.org/jira/browse/DERBY-6670
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Knut Anders Hatlen
> Attachments:
> derby-6670-01-aa-forbidSavepointsWithDeferredConstraints.diff
>
>
> The bug is illustrated by the following code snippet:
> {code}
> Connection c =
> DriverManager.getConnection("jdbc:derby:memory:db;create=true");
> c.setAutoCommit(false);
> Statement s = c.createStatement();
> s.execute("create table t1(x int primary key initially deferred)");
> s.execute("insert into t1 values 1,1,1,1");
> Savepoint sp = c.setSavepoint();
> s.execute("drop table t1");
> c.rollback(sp);
> // Since there are four identical rows in T1, this call should have
> // failed because the primary key was violated.
> c.commit();
> // Instead, it succeeds, and all four rows are committed, as can
> // be seen here:
> ResultSet rs = s.executeQuery("select * from t1");
> while (rs.next()) {
> System.out.println(rs.getInt(1));
> }
> // Insert yet another row, so that we have five identical rows ...
> s.execute("insert into t1 values 1");
> // ... and now commit complains ...
> c.commit();
> {code}
> With auto-commit off, add duplicates into a deferred primary key. Then set a
> savepoint, drop the table, and roll back to the savepoint.
> Apparently, when you drop the table, information about any constraint
> violations seen on that table is lost, and that information is not restored
> when the drop table operation is undone by the rollback to savepoint.
> So when you commit the transaction after having rolled back the drop
> operation, no deferred checking of constraints happens, and the duplicates
> you have inserted are committed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
