db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3379) "No Current connection" on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing
Date Fri, 08 Feb 2008 17:55:12 GMT

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


Mime
View raw message