While working on
DERBY-3172, I found that following 3 JDBC4.0 apis, isValid, isWrapperFor and unwrap on Connection object behave differently in Network Server and Embedded mode after Network Server/Embedded Derby is shutdown. I have attached a reproducible case to show the behavior difference but here is brief description of the problem.
In JDBC4, two methods isWrapperFor and unwrap on Connection object 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 or connection closed exception 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 and connection closed exception.
And lastly, the new JDBC4 api isValid on Connection object has different behavior in client server mode and embedded mode. Embedded throws exception that the connection is down but Network Server incorrectly returns true from isValid even when the Network Server has been shutdown. In addition, in embedded mode, after the engine is shutdown, an isValid call on Connection object raises a connection closed event. In client server mode, after the Network Server is shutdown, an isValid call on Connection object does not raise any event. Again, I am not sure if this is expected bahavior difference between the 2 configurations of Derby. Lastly, as per Connection.isValid api Java specification, a SQLException is thrown under following condition which is not being followed in embedded
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 engine is down.
|Bug behavior facts||[Embedded/Client difference]|
|Priority||Major [ 3 ]||Minor [ 4 ]|
|Workflow||jira [ 12418194 ]||Default workflow, editable Closed status [ 12799493 ]|