Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 02 Aug 2005 10:50:59 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection
 (and session)
In-reply-to: <007f01c59782$5f176ac0$0800a8c0@Arkat>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <42EFB283.7070705@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_/iSRUoLLv7PpqVtgmjEYxA)"
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <1999324040.1122563182740.JavaMail.jira@ajax.apache.org>
 <42E908EE.5050000@sun.com> <42E91364.9030205@sun.com>
 <42E9143C.7090300@debrunners.com> <42E916FC.4000407@sun.com>
 <003401c5943d$968483f0$0800a8c0@Arkat> <007f01c59782$5f176ac0$0800a8c0@Arkat>

This is a multi-part message in MIME format.

--Boundary_(ID_/iSRUoLLv7PpqVtgmjEYxA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT


TomohitoNakayama wrote:

> Hello.
>
> I respond myself (and make a new question).
>
>
>> For example, if application close database by itself , that 
>> application should ensure to close physical connection too.
>> However ,  if connection exists in ConnectionPool, there are no way 
>> to ensure to close physical connection.
>> (This was problem found in DERBY-273. )
>
>
> This  problem to ensure closing physical connection when closing 
> database is considered as next.
>
> Application programs , which uses connection pool , do not close 
> database and
> middleware programs such as application server , which will close 
> database, should manage connection pool using JDBC interface for 
> ConnectionPooling and
> ensure to close connection.
>
> In this meaning, code of DERBY-273 is special because it closes 
> database though not being middleware program .
> // Well , it was not application program but test program , and does 
> not apply our program to anything :)
>
>
I took a look at DERBY-273, and I am very loathe to add a new feature to 
explicitly close a connection just to handle this very edge case.  I 
think in a realy application it is fine if one connection gets a 
ShutdownException because another connection already shut down the 
database.  I personally think that it's *OK* for one connection to shut 
down the database before all connections are closed, this happens all 
the time.  I think the test should catch the ShutdownException and treat 
it as an expected, if intermittent, exception.

>> Another example,even if application does not close database,it is not 
>> out of imagine that connection falls into illegal state and database 
>> administrator wants to kill unhealthy connection .
>> //This would be incompatible to the charter of derby , "zero 
>> administration for end users" ....   :(
>> If the application server that serve the ConnectionPool supports to 
>> kill Connection by administrator, we can leave it.
>> But if the application server does not support, it can be emergency 
>> exit to force closing connection using function of dbms.
>
> This problem is not clear yet, because I don't know what is unhealthy 
> state of connection yet.
> //Sorry for talking what I don't know exactly ....
>
> If there exists such state and it is unavoidable , function to force 
> closing connection would be needed.
>
> Does anyone know such a state of connection in Derby ....?
> I have experienced such states, using other rdbms softwares in 
> situation of rough treatment .......

Yes, I have too, it's pretty common.  But I also don't know if Derby 
gets into these situations.  I know that Oyvind's work on timing out 
transactions is related to this, as this hopefully catches "hung" 
transactions and kills them. 

I suspect that if/when we want to add functionality to "kill" a hung 
connection, the code that Oyvind's writing to do this for timeouts could 
probably be used.

But I would argue that we shouldn't implement this until/unless we 
actually see that such a problem actually exists...

>
>
> 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: Friday, July 29, 2005 10:01 PM
> Subject: Re: [jira] Updated: (DERBY-478) Function to force closing 
> connection (and session)
>
>
>> Hello.
>>
>>> It would be interesting to understand the problem that this 
>>> enhancement is wrestling with.
>>> Nakayama-san, can you shed some more light on your reasons for 
>>> logging this bug?
>>
>>
>> As Dan and Rick says, it is not recommended to close physical 
>> Connection directly when ConnectionPool was used.
>> However ,I think there are cases user reluctantly close physical 
>> Connection.
>>
>> For example, if application close database by itself , that 
>> application should ensure to close physical connection too.
>> However ,  if connection exists in ConnectionPool, there are no way 
>> to ensure to close physical connection.
>> (This was problem found in DERBY-273. )
>>
>> Another example,even if application does not close database,it is not 
>> out of imagine that connection falls into illegal state and database 
>> administrator wants to kill unhealthy connection .
>> //This would be incompatible to the charter of derby , "zero 
>> administration for end users" ....   :(
>> If the application server that serve the ConnectionPool supports to 
>> kill Connection by administrator, we can leave it.
>> But if the application server does not support, it can be emergency 
>> exit to force closing connection using function of dbms.
>>
>> 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: "Rick Hillegas" 
>> <Richard.Hillegas@Sun.COM>
>> To: "Derby Development" <derby-dev@db.apache.org>
>> Sent: Friday, July 29, 2005 2:33 AM
>> Subject: Re: [jira] Updated: (DERBY-478) Function to force closing 
>> connection (and session)
>>
>>
>>> I agree with Dan.
>>>
>>> PooledConnection exposes a getConnection() method which returns its 
>>> wrapped
>>> Connection object. I suspect the intention is that that Connection 
>>> is itself a wrapper whose close()
>>> method deliberately does not close the underlying physical 
>>> Connection. Being able to
>>> close the underlying Connection would work at cross-purposes to the 
>>> whole idea
>>> of Connection pooling.
>>>
>>> It would be interesting to understand the problem that this 
>>> enhancement is wrestling with.
>>> Nakayama-san, can you shed some more light on your reasons for 
>>> logging this bug?
>>>
>>> Thanks,
>>> -Rick
>>>
>>> Daniel John Debrunner wrote:
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> Where in the JDBC 4 spec would this be? I seem to have missed it.
>>>>> There's a fairly long  section on Connection Pooling, but I didn't 
>>>>> see
>>>>> this issue addressed.
>>>>>
>>>>
>>>> I'm not sure it should be. Applications should not have the ability to
>>>> close the underlying physical connection from their logical connection
>>>> object. An api exists to close the physical connection, the close 
>>>> method
>>>> on PooledConnection. But applications do not (and should not) have
>>>> access to PooledConnection.
>>>>
>>>> Dan.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> -Rick
>>>>>
>>>>> David Van Couvering wrote:
>>>>>
>>>>>
>>>>>> Isn't this part of the proposed interfaces for the JDBC 4 spec?
>>>>>>
>>>>>> Tomohito Nakayama (JIRA) wrote:
>>>>>>
>>>>>>
>>>>>>>    [ http://issues.apache.org/jira/browse/DERBY-478?page=all ]
>>>>>>>
>>>>>>> Tomohito Nakayama updated DERBY-478:
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>>       Summary: Function to force closing connection (and 
>>>>>>> session) (was: Force to close connection and session)
>>>>>>>   Description: When connection exists in ConnectionPool , there are
>>>>>>> no way to ensure closing connection inside the ConnectionPool from
>>>>>>> application program just using jdbc interface.
>>>>>>>
>>>>>>> I think there exists needs to force closing connection when it is
>>>>>>> needed to ensure closing of connection.  was:When connection exists
>>>>>>> in ConnectionPool , there are no way to ensure
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Function to force closing connection (and session)
>>>>>>>> --------------------------------------------------
>>>>>>>>
>>>>>>>>        Key: DERBY-478
>>>>>>>>        URL: http://issues.apache.org/jira/browse/DERBY-478
>>>>>>>>    Project: Derby
>>>>>>>>       Type: Improvement
>>>>>>>> Components: Network Server
>>>>>>>>   Reporter: Tomohito Nakayama
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> When connection exists in ConnectionPool , there are no way to
>>>>>>>> ensure closing connection inside the ConnectionPool from 
>>>>>>>> application
>>>>>>>> program just using jdbc interface.
>>>>>>>> I think there exists needs to force closing connection when it is
>>>>>>>> needed to ensure closing of connection.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.338 / Virus Database: 267.9.6/59 - Release Date: 
>>> 2005/07/27
>>>
>>>
>>
>>
>>
>> -- 
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 2005/07/28
>>
>>
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 2005/07/28
>>
>>
>
>
>

--Boundary_(ID_/iSRUoLLv7PpqVtgmjEYxA)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=david.vancouvering.vcf

begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@sun.com
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard


--Boundary_(ID_/iSRUoLLv7PpqVtgmjEYxA)--