db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-94) Lock not being released properly, possibly related to occurence of lock escalation
Date Tue, 07 Dec 2004 23:17:11 GMT
     [ 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


Mime
View raw message