You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/08/01 16:17:49 UTC
Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
Hello.
I have overviewed jdbc-4_0-edr-spec.pdf , and found next description for new feature of JDBC4.0 , chapter 3.1 Overview of changes in
page 12.
>Connection Management
>Additional enhancements to Connection and improved connection state tracking, and greater
>Statement objects in pool environments.
However, improved connection state tracking seems to mean just be able to track the state and
does not mean ability to change state of connection.
In the same page 12 , specification describe new method added to Connection interface.
>■ Connection
>Added the methods createBlob, createClob, createNClob,createQueryObject, isValid, createXML, getClientInfo,setClientInfo.
There exists "isValid" but not "setValid".
Then, I think it is impossible for JDBC 4.0 to force closing connection.
Just be able to diagnose connection.
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" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, July 30, 2005 4:06 PM
Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
> Hello.
>
> Can you give me time to see JDBC extensions ?
> I have surveyed JDBC3.0 , jdbc-3_0-fr-spec.pdf, but have not surveyed JDBC4.0 .
>
> I think I need to survey JDBC4.0 too.
> //And it would be wise to wait discussing about this for the survey of JDBC 4.0 :)
>
> 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: "David Van Couvering" <Da...@Sun.COM>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, July 30, 2005 3:38 AM
> Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
>
>
>> Sorry if I'm missing something, but if we end up agreeing that this is needed, doesn't this require a non-standard extension to
>> the JDBC API?
>>
>> Thanks,
>>
>> David
>>
>> TomohitoNakayama wrote:
>>
>>> 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" <Ri...@Sun.COM>
>>> To: "Derby Development" <de...@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 incoming 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 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
>
>
--
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
Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Talking with others , I have come to think the code in DERBY-273 was special ,
because ordinary application program does not shutdown database.
I might stand on that basis ....
How others think about ?
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" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, August 01, 2005 11:17 PM
Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
> Hello.
>
> I have overviewed jdbc-4_0-edr-spec.pdf , and found next description for new feature of JDBC4.0 , chapter 3.1 Overview of changes
> in
> page 12.
>
>>Connection Management
>>Additional enhancements to Connection and improved connection state tracking, and greater
>>Statement objects in pool environments.
>
> However, improved connection state tracking seems to mean just be able to track the state and
> does not mean ability to change state of connection.
>
> In the same page 12 , specification describe new method added to Connection interface.
>
>>■ Connection
>>Added the methods createBlob, createClob, createNClob,createQueryObject, isValid, createXML, getClientInfo,setClientInfo.
>
> There exists "isValid" but not "setValid".
>
> Then, I think it is impossible for JDBC 4.0 to force closing connection.
> Just be able to diagnose connection.
>
> 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" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, July 30, 2005 4:06 PM
> Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
>
>
>> Hello.
>>
>> Can you give me time to see JDBC extensions ?
>> I have surveyed JDBC3.0 , jdbc-3_0-fr-spec.pdf, but have not surveyed JDBC4.0 .
>>
>> I think I need to survey JDBC4.0 too.
>> //And it would be wise to wait discussing about this for the survey of JDBC 4.0 :)
>>
>> 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: "David Van Couvering" <Da...@Sun.COM>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, July 30, 2005 3:38 AM
>> Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
>>
>>
>>> Sorry if I'm missing something, but if we end up agreeing that this is needed, doesn't this require a non-standard extension to
>>> the JDBC API?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> 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" <Ri...@Sun.COM>
>>>> To: "Derby Development" <de...@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 incoming 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 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
>>
>>
>
>
>
> --
> 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
>
--
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