db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4172) You can open a read-write connection to a database which was originally opened by another thread using the classpath subprotocol
Date Tue, 21 Apr 2009 21:07:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701267#action_12701267
] 

Dag H. Wanvik commented on DERBY-4172:
--------------------------------------

It seems another database instance is opened "on top" of the read-only one, since the read-only
database places no lock file (reasonably enough), Derby doesn't figure out that when the file
based boot takes place, we are really dealing with the same database, so another instance
is booted. In short, to Derby, they are two different databases :(

> You can open a read-write connection to a database which was originally opened by another
thread using the classpath subprotocol
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4172
>                 URL: https://issues.apache.org/jira/browse/DERBY-4172
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.6.0.0
>            Reporter: Rick Hillegas
>
> The original connection, using the classpath subprotocol, was supposed to open the DATABASE
(not the connection) as read-only, according to the Developer's Guide section titled "Database
connection examples". However, I am able to write to this database in another connection which
opens the database using the default, file-based protocol.
> At a minimum, the documentation is wrong. But the documentation may be trying to impose
a consistent, easily described model on the behavior of our subprotocols. It may be that the
behavior of our subprotocols cannot be described by a simple set of rules that users can grasp
easily.
> To show this problem, I created a database and then moved it into a directory on my classpath
(in this case, trunk/classes). Here is a script which shows this behavior:
> connect 'jdbc:derby:classpath:derby10.6' as conn1;
> -- fails because a database which is opened on the classpath is supposed to be marked
as read-only
> insert into t( a ) values 1;
> connect 'jdbc:derby:trunk/classes/derby10.6' as conn2;
> -- this succeeds even though the database is supposed to be read-only
> -- according to the Developer's Guide section "Database connection examples"
> insert into t( a ) values 2;
> select * from t;
> delete from t;

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


Mime
View raw message