Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1116891774.1240324307758.JavaMail.jira@brutus>
Date: Tue, 21 Apr 2009 07:31:47 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4171) Connections to on-disk db go to
 in-memory db if in-memory db with same name is booted
In-Reply-To: <1501248569.1240233587470.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Hillegas commented on DERBY-4171:
--------------------------------------

Thanks for thinking about this issue, Knut and Kristian. What do you think the behavior should be:

1) The memory subprotocol defines a separate namespace of databases. In this situation, it should be possible to have two databases with the same name, one in the memory namespace and one in the namespace accessed by all other subprotocols

or

2) The first thread to open a database defines which subprotocols must be used to access the database from other connections--until the database is brought down. If a database was first opened by the memory subprotocol, then a database by that name cannot be accessed simultaneously by any other subprotocol. Conversely, if a database was first opened by the default or classpath subprotocols, then a database by that name cannot be accessed simultaneously by the memory subprotocol.

I have two worries:

A) We may not understand the current behavior of our subprotocols well enough. See DERBY-4172.

B) The code may assume that there is only one namespace for databases. Adding another namespace may be tricky.

I think I would lean toward (2). If we later decide that (2) is too restrictive and we think we understand the code well enough, then we could migrate to (1) without causing serious compatibility issues. I think that going from (1) to (2) will have serious compatibility implications.

> Connections to on-disk db go to in-memory db if in-memory db with same name is booted
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-4171
>                 URL: https://issues.apache.org/jira/browse/DERBY-4171
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.1.1
>            Reporter: Knut Anders Hatlen
>         Attachments: derby-4171-1a-fix.diff
>
>
> When an in-memory database has been booted, subsequent attempts to connect to an ordinary (on-disk) database with the same name as the in-memory database will connect to the in-memory db.
> ij version 10.5
> ij> connect 'jdbc:derby:memory:MyDB;create=true'; -- with subprotocol memory
> ij> create table t (x varchar(30));
> 0 rows inserted/updated/deleted
> ij> insert into t values 'This is the in-memory backend';
> 1 row inserted/updated/deleted
> ij> connect 'jdbc:derby:MyDB;create=true'; --without subprotocol memory, should create disk db
> WARNING 01J01: Database 'MyDB' not created, connection made to existing database instead.
> ij(CONNECTION1)> select * from t;
> X                             
> ------------------------------
> This is the in-memory backend 
> 1 row selected

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