[ http://issues.apache.org/jira/browse/DERBY-94?page=all ]
Sunitha Kambhampati updated DERBY-94:
-------------------------------------
Fix Version: 10.1.1.0
> Lock not being released properly, possibly related to occurence of lock
> escalation
> ----------------------------------------------------------------------------------
>
> Key: DERBY-94
> URL: http://issues.apache.org/jira/browse/DERBY-94
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.0.2.1
> Environment: all
> Reporter: Sunitha Kambhampati
> Assignee: Suresh Thalamati
> Fix For: 10.1.1.0
> 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://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
