[ 
https://issues.apache.org/jira/browse/DERBY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-911:
--------------------------------

    Issue & fix info: [Repro attached]
             Urgency: Normal

Triaged for 10.5.3: assigned normal urgency and noted that a repro is attached.

> Connection.setReadOnly is a no-op in Network Client. It works fine with 
> embedded client.
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-911
>                 URL: https://issues.apache.org/jira/browse/DERBY-911
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.2.1.6
>            Reporter: Mamta A. Satoor
>
> I have a simple test program which calls the Connection.setReadOnly(true) and 
> then checks the readonly mode of that connection. In Network Server mode, the 
>  Connection.isReadOnly returns false even after Connection.setReadOnly(true). 
> Same test program works fine when run in embedded mode, ie 
> Connection.isReadOnly returns true after Connection.setReadOnly(true) is 
> executed. 
> Following is the test code snippet
> con = 
> DriverManager.getConnection("jdbc:derby://localhost:1527/db7173;create=true", 
> "APP", "APP");
> System.out.println("Check default connection.isReadOnly " + con.isReadOnly());
> con.setReadOnly(true);
> System.out.println("After connection.setReadOnly(true), what is isReadOnly " 
> + con.isReadOnly());
> The output of this code in Network Server is as follows
> Check default connection.isReadOnly? false
> After connection.setReadOnly(true), what is isReadOnly? false
> I looked at the Network Client code and found the problem to be in the 
> Network Client.   
> org.apache.derby.client.am.Connection.setReadOnly method simply doesn't do 
> anything with the supplied value, ie it doesn't pass any information to the 
> Network Server for this call. In addition, it has following comment 
>      // This is a hint to the driver only, so this request is silently 
> ignored.
>      // PROTOCOL can only flow a set-read-only before the connection is 
> established.
> In the same class, isReadOnly always returns false. This explains the current 
> behavior of Network Server. But are we really limited by the DRDA protocol 
> here as the comments in setReadOnly seem to imply?
> Anyone more familiar with DRDA specification and/or this code in Derby, can 
> they share any information on DRDA spec and Derby behavior in this area?

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

Reply via email to