You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/02/08 18:55:12 UTC

[jira] Commented: (DERBY-3379) "No Current connection" on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing

    [ https://issues.apache.org/jira/browse/DERBY-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567132#action_12567132 ] 

Kristian Waagan commented on DERBY-3379:
----------------------------------------

I had a look at this one.

After some DRDA debugging and various ad-hoc tests, I think I have a basic idea of what is happening.
Note that there are several problems with the current implementation.

First of all, the "No current connection" exception is thrown in the client because the client side state of the connection is not maintained/handled properly. The variable 'open_' in the connection is false (but 'availableForReuse' is true) and the exception is raised when you try to create a new logical connection.

Secondly, the client driver has the same bug as the embedded driver regarding nulling out the connection pointers.

Finally, when getting past the obstacles above, the test causes Derby to hang.
I found out that the reason is that the chaining bits indicate there is more to come from the client, so the server doesn't send the reply.
This is in fact wrong, and both sides end up waiting for each other.

After some more testing and code review, I found out that opening a ResultSet before closing the statement in the test makes the hang go away. This is because the client has to send a command to the server asking it to close the ResultSet, and this time the chaining bit is apparently set correctly.


I'm a bit unsure how to proceed with fixing this bug. I'm assuming the reset is required, which indicates we somehow have to make sure the chaining bit of the deferred reset is set correctly. The most obvious fix now I can see right away, is to make sure we end the chain if there are no other commands going to the server.
For instance, can we force the last chaining bit to indicate no chaining in Agent.endWriteChain, or will this break something?
(transmission of large continued objects, bigger than 32K?)
Maybe we have to take the continuation bits into account as well?

If someone wants to have a closer look, the reset commands are constructed as part of the ClientPooledConnection.close method, and the commands are pushed onto the wire as part of Statement.close in the test (DataSourceTest.testPooledReuseOnClose).

I haven't worked much with the client code, so some advice would be helpful.

> "No Current connection" on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3379
>                 URL: https://issues.apache.org/jira/browse/DERBY-3379
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
>            Reporter: Kathey Marsden
>
> This is the client version of bug DERBY-2142.  It can be reproduced by enabling the test, DataSourceTest.testPooledReuseOnClose() for client. I am opening a new issue for client as the embedded fix was backported to 10.1 and I am guessing the client fix won't be backported that far.  Better to keep it as  a separate issue.
>  

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