[
https://issues.apache.org/jira/browse/DERBY-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510584
]
Andrew McIntyre commented on DERBY-2451:
----------------------------------------
I tried to reproduce this issue as described in the original issue description
and I was unable to reproduce the problem. After editing SQL Workbench/J's
driver configuration to allow connecting via the ClientDriver, I opened up a
connection with the first window from SQL Workbench/J, and then performed a
create, insert and then a select on a new table. I then left this window open.
I then used the 'New Window' function in the file menu of SQL Workbench/J to
open a new window and connect to the same database separately. I then selected
from the same table accessed by the first client, which provided the same
results as from the first network client's select, and then used the Disconnect
function from the File menu to disconnect the second client that I opened. A
subsequent select issued from the first SQL Workbench/J window completed
successfully, and I was able to see the results. I then issued another insert
and then a select, and was then also able to see new inserted values.
I issued another 'New Window', connected a third client, and selected from the
same table and SQLWorkbench/J showed the new results with no errors. I
disconnected this third client, and I was then able to select from the same
table with the first client and get the same results as just selected from the
disconnected third client.
Unless the reporter of this issue can provide a more specific set of
instructions for reproducing the issue, I suggest that it be closed as 'Cannot
Reproduce'.
> a client can crash connections of another client
> ------------------------------------------------
>
> Key: DERBY-2451
> URL: https://issues.apache.org/jira/browse/DERBY-2451
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.2.2.0
> Reporter: quartz
> Priority: Critical
>
> Using 10.2.2.0.
> Steps to reproduce:
> 1-Start a NetworkServerControl
> 2-Start a 1st client (sqlworkbench/J), show some rows of some db, table X
> (stay connected)
> 3-Start a 2nd client (sqlworkbench/J), show some rows of some db, table X.
> 4-disconnect 2nd client
> 5-redo the 1st client query (refresh)
> You get a non architected message, sqlstate 58009, db errorcode -4499.
> In derby log, I see a shutdown of the database, and a restart.
> No matter how badly and corrupted a client connection can get, nor if the
> client connection is
> a bug in any client, such corruption should never destabilise a "server",
> certainly not other clients connections.
> It may be that the client tries to shutdown the DB; it shouldn't have such
> privilege anyway since it
> is a network "client" connection, NOT an embedded connection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
