Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <24233127.1196146963395.JavaMail.jira@brutus>
Date: Mon, 26 Nov 2007 23:02:43 -0800 (PST)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Issue Comment Edited: (DERBY-3172)
 ConnectionEventListener.connectionErrorOccurred not being executed when
 SQLState 08006 Error is thrown
In-Reply-To: <20584897.1193966810651.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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