db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-911) Connection.setReadOnly is a no-op in Network Server. It works fine in embedded Derby.
Date Thu, 02 Feb 2006 07:41:04 GMT
Connection.setReadOnly is a no-op in Network Server. It works fine in embedded Derby.
-------------------------------------------------------------------------------------

         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, 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?


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


Mime
View raw message