[ http://nagoya.apache.org/jira/browse/DERBY-94?page=history ]
Sunitha Kambhampati updated DERBY-94:
-------------------------------------
Attachment: Derby94Test.java
Derby94Test_Output
derby.log
Program to reproduce the problem described in Derby 94.
To run the program
java -Dderby.locks.escalationThreshold=110 -Dderby.locks.deadlockTrace=true
Derby94Test
Derby94Test_Output is a sample output of the lock table information that is
written out to standard out. Note in the second iteration a lock timeout error
is thrown.
Derby.log has the lock timeout exception
> Lock not being released properly, possibly related to occurence of lock
> escalation
> ----------------------------------------------------------------------------------
>
> Key: DERBY-94
> URL: http://nagoya.apache.org/jira/browse/DERBY-94
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.0.2.1
> Environment: all
> Reporter: Sunitha Kambhampati
> Attachments: Derby94Test.java, Derby94Test_Output, derby.log
>
> In the following scenario:
> <code snippet>
> String sel = "select * from t1 FOR UPDATE of i2";
> PreparedStatement ps1 = conn.prepareStatement (sel);
> int val = 300;
> ps1.setMaxRows(val);
> ResultSet rs = ps1.executeQuery();
> String ins = "Update t1 set i2=? WHERE CURRENT OF
> "+rs.getCursorName() ;
> PreparedStatement ps2 = conn.prepareStatement(ins);
> ps2.setInt(1,iteration);
> while(rs.next())
> {
> ps2.executeUpdate();
> };
> // print lock table information
> System.out.println("Lock Table before commit transaction");
> printLockTable(conn);
> conn.commit();
> <end code snippet>
> Running the above transaction twice causes a lock timeout the second time.
> It seems like locks are not being released properly on the table even after
> the transaction commits and the connection is closed. Also, this condition
> seems to happen only when lock escalation to table lock occurs. By
> increasing lock escalation threshold to prevent lock escalation and with
> only row level locking, the locks are released properly.
> I printed out the locks information and see a U row level lock on the table ,
> and also a table level lock as a result of lock escalation. After commit, and
> resultset being closed, the U row level lock is not released. Thus in the
> second iteration of the test, the unreleased U row level lock causes a lock
> timeout to happen. In case of the second iteration of the test, the lock
> table shows the previous U row lock with a null transaction id. This is not
> right.
> The transactions are running at the default isolation level ( read committed).
> By default, the lock escalation threshold is set to 5000
> http://incubator.apache.org/derby/manuals/tuning/perf80.html#IDX547
> I will be attaching the program for reproduction. To reproduce the problem
> with less number of rows in the table, please run the program with the
> following derby properties set
> derby.locks.deadlockTrace=true
> derby.locks.escalationThreshold=110
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
