[
https://issues.apache.org/jira/browse/DERBY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-911:
---------------------------------
Derby Categories: [Embedded/Client difference]
> 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.
