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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "TomohitoNakayama"
<[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "Rick Hillegas"
<[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
