db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject My descision for DERBY-397
Date Wed, 20 Jul 2005 15:21:35 GMT
Hello.

I concluded to do nothing for DERBY-397 for now.

Reasons were as next.

1:
EmbedConnection , which drda module uses , assumes transaction is inactive when connection
was closed.
Then, it is illegal in current structure of drda module to close connection when rollback
was failed.

// I came to suspect that it is not good structure for drda module to use EmbedConnection
directly .


2:
There are no fact that it causes obvious problem not to call close in drda.Database#close()
when rollback() was failed .
On the other hand, there are risks to call close when rollback() was failed and not calling
rollback().

It seems to be  lesser profit and more danger.


3:
At least Database#close() ensure Database#conn to be null and we can expect EmbedConnection#finalize()
to be called.



Best regards.


/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp
         tmnk@apache.org

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "TomohitoNakayama" <tomonaka@basil.ocn.ne.jp>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Wednesday, July 20, 2005 9:03 PM
Subject: result of jdbcTrans (Re: [jira] Commented: (DERBY-397) Make it sure for the connection
to be closed in 
drda.Database#close() even if Exception happens in conn.rollback().)


> 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:
> ====================
> naka@nysalor:~/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...
> naka@nysalor:~/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:
> ===================
> naka@nysalor:~/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
>         tomonaka@basil.ocn.ne.jp
>         tomohito@rose.zero.ad.jp
>         tmnk@apache.org
>
>         Naka
>         http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- 
> From: "Rajesh Kartha (JIRA)" <derby-dev@db.apache.org>
> To: <derby-dev@db.apache.org>
> 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
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 2005/07/19
>
> 



-- 
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


Mime
View raw message