[ 
http://issues.apache.org/jira/browse/DERBY-397?page=comments#action_12315556 ] 

Tomohito Nakayama commented on DERBY-397:
-----------------------------------------

I could remember what I thought when coding it ...

Thinking that user need to make transaction inactive state always when closing 
it,
executing rollback() in drda.Database#close() have meaning only when connection 
is forced to close by something other than user e.g. accidential network 
disconnection.

In such a case of closing connection, 
I thought there are no need to make transaction inactive state even if closing 
it.
Then I made new close method which does not check transaction, and called it 
from drda.Database#close().

Of cource , 
there were anxiety that transactional state of connection need to be inactive 
when closing it , 
not just because checking code exists but because closure of connection 
essentially require transaction to be inactive.

Then , I tested it by derbyall and could not found (some kind of expected...) 
error.


Well ... lock timeout issue may have something to do with this ....

> 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

Reply via email to