Hello Rajesh and all. Sorry for my late response for this.
I executed test of jdbcTrans and could not found lock timeout error.
Next is log of testing.
/////////////////////////////////////////////
terminal to execute jdbcTrans:
====================
[EMAIL PROTECTED]:~/ProgramDev/testDerby/DERBY-397$ java -classpath ".:../lib/db2jcc.jar:../lib/db2jcc_license_c.jar" jdbcTrans
com.ibm.db2.jcc.DB2Driver jdbc:derby:net://localhost:1527/adb usr pw
Auto-Commit is false
Table exists...
Inserting rows..
Completed inserts...
Exiting...
[EMAIL PROTECTED]:~/ProgramDev/testDerby/DERBY-397$ java -classpath ".:../lib/derbyclient.jar" jdbcTrans
org.apache.derby.jdbc.ClientDriver jdbc:derby://localhost:1527/adb usr pwd
Auto-Commit is false
Table exists...
Inserting rows..
Completed inserts...
Exiting...
terminal to execute ij.ksh:
===================
[EMAIL PROTECTED]:~/ProgramDev/testDerby/20050720$ ij.ksh
ij version 10.2
ij> connect 'jdbc:derby://localhost/adb';
ij> select * from usr.tab1;
ID |COL1
----------------
0 rows selected
ij> autocommit off;
ij> select * from usr.tab1;
ID |COL1
----------------
0 rows selected
ij>
///////////////////////////////////////
Hmm .........
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Rajesh Kartha (JIRA)" <[email protected]>
To: <[email protected]>
Sent: Tuesday, July 12, 2005 3:46 AM
Subject: [jira] Commented: (DERBY-397) Make it sure for the connection to be closed in drda.Database#close() even if Exception
happens in conn.rollback().
[
http://issues.apache.org/jira/browse/DERBY-397?page=comments#action_12315507 ]
Rajesh Kartha commented on DERBY-397:
-------------------------------------
I remember coming across a Network Server issue - some time middle of last
year, where with AutoCommit=OFF, while
performing a transaction exits in the middle without an
explicit commit()/rollback(), the locks held on the table are not
released and the connection needs to be cleaned up.
A subsequent query on the table gets the SQLSTATE: 40XL1 -
Lock timeout error.
This issue was fixed.
I am attaching a repro of the earlier problem. Can you please make sure that
the above fixes for DERBY-397
does not cause a regression.
To run the script:
1) Start the Network Server and create a database 'adb'
2) Run the java app:
-- using the JCC driver:
java jdbcTrans com.ibm.db2.jcc.DB2Driver
jdbc:cloudscape:net://localhost:1527/adb usr pwd
-- since this was Network server related, I would assume it could be
reproduced with the DerbyClient too
java jdbcTrans org.apache.derby.jdbc.ClientDriver
jdbc:derby://localhost:1527/adb usr pwd
3) In a new ij window, connect to the db 'adb'
- Execute a 'Select * from usr.tab1', you could see the query
hang and then a timeout after the default LOCK timeout value.
Make it sure for the connection to be closed in drda.Database#close() even if
Exception happens in conn.rollback().
-------------------------------------------------------------------------------------------------------------------
Key: DERBY-397
URL: http://issues.apache.org/jira/browse/DERBY-397
Project: Derby
Type: Sub-task
Components: Network Server
Reporter: Tomohito Nakayama
Assignee: Tomohito Nakayama
Attachments: derbyall_pass.txt, derbyall_report.txt, jdbcTrans.java,
surveyDERBY397.patch.txt
If exeption was happen in conn.rollback() In the code of drda.Database#close,
that connection was not closed and would be leaked.
http://svn.apache.org/repos/asf/incubator/derby/code/trunk/java/drda/org/apache/derby/impl/drda/Database.java
Make it sure to close connection between drda and engine, when
drda.Database#close was called.
--
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
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.11/45 - Release Date: 2005/07/09
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 2005/07/19
