[ http://issues.apache.org/jira/browse/DERBY-911?page=all ]
Mamta A. Satoor updated DERBY-911:
----------------------------------
Summary: Connection.setReadOnly is a no-op in Network Client. It works
fine with embedded client. (was: Connection.setReadOnly is a no-op in Network
Server. It works fine in embedded Derby.)
Description:
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?
was:
I have a simple test program which calls the Connection.setReadOnly(true) and
then checks the readonly mode of that connection. In Network Server, 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 org.apache.derby.client.am.Connection.setReadOnly method and
noticed that the method simply doesn't do anything with the supplied value. 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?
I have changed the wordings to use Network Client where it seemed appropriate.
If I missed anything, let me know.
> Connection.setReadOnly is a no-op in Network Client. It works fine with
> embedded client.
> ----------------------------------------------------------------------------------------
>
> Key: DERBY-911
> URL: http://issues.apache.org/jira/browse/DERBY-911
> Project: Derby
> Type: Bug
> Components: Network Client
> Versions: 10.2.0.0
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
