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 Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)
Date Wed, 03 Aug 2005 10:40:52 GMT
Hello.

> 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'm not sure this is edge case.
However I think application program that use but cannot manage connection pooling ,
should not close database.
//I think database have more impact than connectionPooling ...

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

When this kind of ShutdownException have occured in shutting down database, 
some transaction was likely to be ended up without rollback.
I understand recovery processing will be run at restarting database in such a case , however,

I feel unpleasant for the siituation.

Now, I belive the program of DERBY-273 is not application program , but test program.


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

I asked wheter someone have seen , and there was no report .
I agree we should not until .


Then, I will close this issue as Cannot Reproduce.


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" <David.Vancouvering@Sun.COM>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Wednesday, August 03, 2005 2:50 AM
Subject: Re: [jira] Updated: (DERBY-478) Function to force closing connection (and session)


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


--------------------------------------------------------------------------------


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.9/62 - Release Date: 2005/08/02


Mime
View raw message