db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3172) ConnectionEventListener.connectionErrorOccurred not being executed when SQLState 08006 Error is thrown
Date Tue, 27 Nov 2007 07:02:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543190
] 

mamtas edited comment on DERBY-3172 at 11/26/07 11:01 PM:
-------------------------------------------------------------------

Just committed a change into trunk through 595803 which should take care of DataSourceTest
failure. The commit comments are as follows

This is a followup checkin to checkin(595047) was committed for DERBY-3172. The DataSourceTest
had started failing under JDK1.6 after 595047. The particular test case that was failing was
for Connection.getTypeMap The reason for failure was that this method was overridden in a
subclass which kicks in only when JDBC4.0 is available. The overriden method was not sending
the correct connection error event as expected by the test and hence the failure. While fixing
this, I realized that there are several new JDBC4.0 apis that need to send the correct events
to ConnectionEventListeners. This checkin takes care of those apis. More info on what was
changed in this commit is as follows.

New JDBC4.0 api, setClientInfo, wraps SQLException inside SQLClientInfoException but we were
not copying the error code of SQLException into SQLClientInfoException. Without the correct
error code, we would not send connection error event because the severity has to be fatal
for us to send connection error event. Because of this, I had to change several places where
SQLException is wrapped inside SQLClientInfoException to pass SQLException's error code to
SQLClientInfoException. The classes changed because of this are EmbedConnection40, BrokeredConnection40,
NetConnection40.

For methods that throw SQLClientInfoException, we were not notifying the connection error
events. I made changes to fix this.

Several of new JDBC4 apis on connection object were not sending error events so I changed
those methods in BrokeredConnection40 and LogicalConnection40. 

BrokeredConnection40 implements new JDBC4 methods on Connection object but these new methods
did not follow the same logic as the other existing pre-JDBC4 methods to check for connection
close and that caused the events to be not sent correctly. The problematic apis were createBlob,
createClob, isWrapperFor, unwrap and I fixed those.

Not all the new JDBC4 apis have been implemented (they throw not implemented exception) so
the tests written for those apis just catch the unimplemented exception. These methods include
createArrayOf, createNClob, createSQLXML, createStruct.

In JDBC4, Connection object has two methods isWrapperFor and unwrap which do not go to the
server when Derby is being accessed in client server mode and because of this, we never detect
that the server is down and hence no connection error event is thrown in client server mode
for these 2 apis. But when the same apis are called in embedded Derby after the engine is
shutdown, we get connection error event. I have added the test for these 2 apis to count for
the different in behavior but I am not sure if this is the expected behavior difference between
the 2 configurations of Derby. I will enter a Jira entry for this.

And lastly, the new JDBC4 api isValid on Connection object has different behavior in client
server mode and embedded mode. They both throw exception that the connection is down but the
connection close and error events are not dealt the same way in the 2 configurations. In embedded
mode, after the engine is shutdown, an isValid call on Connection object raises a connection
closed event and no connection error event. In client server mode, after the Network Server
is shutdown, an isValid call on Connection object does not raise any event. In both the configurations,
we do get a SQLException stating that connection is down. Again, I am not sure if this is
expected bahavior difference between the 2 configurations of Derby. I will enter a Jira entry
for this too. In addition, as per Connection.isValid api Java specification, a SQLException
is thrown under following condition which is not being followed in embedded and client-server
mode
Throws: 
SQLException - if the value supplied for timeout is less then 0
Based on this, I am not sure if our behavior is correct to throw an SQLException if the server/engine
is down. I will include this information in the Jira entry that I will make.

The tests for all these new JDBC4 apis are in jdbc4/DataSourceTest.  

I moved the AssertEventCatcher class implementation from jdbcapi/DataSourceTest into a class
of it's own. This way, it can be shared by jdbcapi/DataSourceTest and jdbc4/DataSourceTest.

      was (Author: mamtas):
    Just committed a change into trunk through 595803 which should take care of DataSourceTest
failure. The commit comments are as follows

This is a followup checkin to checkin(595050) was committed for DERBY-3172. The DataSourceTest
had started failing under JDK1.6 after 595050. The particular test case that was failing was
for Connection.getTypeMap The reason for failure was that this method was overridden in a
subclass which kicks in only when JDBC4.0 is available. The overriden method was not sending
the correct connection error event as expected by the test and hence the failure. While fixing
this, I realized that there are several new JDBC4.0 apis that need to send the correct events
to ConnectionEventListeners. This checkin takes care of those apis. More info on what was
changed in this commit is as follows.

New JDBC4.0 api, setClientInfo, wraps SQLException inside SQLClientInfoException but we were
not copying the error code of SQLException into SQLClientInfoException. Without the correct
error code, we would not send connection error event because the severity has to be fatal
for us to send connection error event. Because of this, I had to change several places where
SQLException is wrapped inside SQLClientInfoException to pass SQLException's error code to
SQLClientInfoException. The classes changed because of this are EmbedConnection40, BrokeredConnection40,
NetConnection40.

For methods that throw SQLClientInfoException, we were not notifying the connection error
events. I made changes to fix this.

Several of new JDBC4 apis on connection object were not sending error events so I changed
those methods in BrokeredConnection40 and LogicalConnection40. 

BrokeredConnection40 implements new JDBC4 methods on Connection object but these new methods
did not follow the same logic as the other existing pre-JDBC4 methods to check for connection
close and that caused the events to be not sent correctly. The problematic apis were createBlob,
createClob, isWrapperFor, unwrap and I fixed those.

Not all the new JDBC4 apis have been implemented (they throw not implemented exception) so
the tests written for those apis just catch the unimplemented exception. These methods include
createArrayOf, createNClob, createSQLXML, createStruct.

In JDBC4, Connection object has two methods isWrapperFor and unwrap which do not go to the
server when Derby is being accessed in client server mode and because of this, we never detect
that the server is down and hence no connection error event is thrown in client server mode
for these 2 apis. But when the same apis are called in embedded Derby after the engine is
shutdown, we get connection error event. I have added the test for these 2 apis to count for
the different in behavior but I am not sure if this is the expected behavior difference between
the 2 configurations of Derby. I will enter a Jira entry for this.

And lastly, the new JDBC4 api isValid on Connection object has different behavior in client
server mode and embedded mode. They both throw exception that the connection is down but the
connection close and error events are not dealt the same way in the 2 configurations. In embedded
mode, after the engine is shutdown, an isValid call on Connection object raises a connection
closed event and no connection error event. In client server mode, after the Network Server
is shutdown, an isValid call on Connection object does not raise any event. In both the configurations,
we do get a SQLException stating that connection is down. Again, I am not sure if this is
expected bahavior difference between the 2 configurations of Derby. I will enter a Jira entry
for this too. In addition, as per Connection.isValid api Java specification, a SQLException
is thrown under following condition which is not being followed in embedded and client-server
mode
Throws: 
SQLException - if the value supplied for timeout is less then 0
Based on this, I am not sure if our behavior is correct to throw an SQLException if the server/engine
is down. I will include this information in the Jira entry that I will make.

The tests for all these new JDBC4 apis are in jdbc4/DataSourceTest.  

I moved the AssertEventCatcher class implementation from jdbcapi/DataSourceTest into a class
of it's own. This way, it can be shared by jdbcapi/DataSourceTest and jdbc4/DataSourceTest.
  
> ConnectionEventListener.connectionErrorOccurred not being executed when SQLState 08006
Error is thrown
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3172
>                 URL: https://issues.apache.org/jira/browse/DERBY-3172
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.1.4
>            Reporter: Stan Bradbury
>            Assignee: Mamta A. Satoor
>         Attachments: DerbyNotification2.java
>
>
> The attached program demonstrates the problem.  Using the ClientConnectionPoolDataSource40
with a connectionEventListener the defined method connectionErrorOccurred is not executed
after the Network Server is shutdown and activity is performed on a previously established
pooled connection.
> Program also demonstrates that the connectionClosed method is executed when the connection
is closed.
> To run the reproduction:
> 1) start network server (listening on default host/port and  -noSecurityManager specified)
> 2) run the program
> Output is:
>  > java DerbyNotification2
> 10.3.1.5 - (579866)
> Apache Derby
>  .got connection...check if connectionClosed method is called
> EVENT CALLED: Connection closed happened
>  . . .
>  . . .Get connection and issue test SQL statement
>  . . .AS EXPECTED: no table exists
>  . SHUTDOWN Network server and check if connectionErrorOccurred is called
> now try to use the connection after the NS is STOPPED
> SQLState is: 08006
> Error is: -4499
> Message is: Insufficient data while reading from the network - expected a minimum of
6 bytes and received only -1 bytes.  The connection has been terminated.
> Exception in thread "main" java.sql.SQLNonTransientConnectionException: Insufficient
data while reading from the network - expected a minimum of 6 bytes and received only -1 bytes.
 The connection has
>  been terminated.
>         at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
>         at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
>         at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source)
>         at org.apache.derby.client.am.LogicalConnection.prepareStatement(Unknown Source)
>         at DerbyNotification2.runTest(DerbyNotification2.java:64)
>         at DerbyNotification2.main(DerbyNotification2.java:87)
> Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data while reading
from the network - expected a minimum of 6 bytes and received only -1 bytes.  The connection
has been termina
> ted.
>         at org.apache.derby.client.net.Reply.fill(Unknown Source)
>         at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown Source)
>         at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
>         at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown Source)
>         at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown
Source)
>         at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown
Source)
>         at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown
Source)
>         at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source)
>         at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown
Source)
>         at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown
Source)
>         at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
>         at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source)
>         ... 4 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message