db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kim Haase (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4525) Document the in-memory storage back end
Date Tue, 09 Mar 2010 16:27:27 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843183#action_12843183

Kim Haase commented on DERBY-4525:

Thanks, Knut! I've linked to DERBY-4428 to have that info handy.

It is true that the issues in the two topics are different -- thanks for pointing that out.
"One Derby instance for each Java Virtual Machine" is not the same thing as "One Derby instance
for each database". So they should both stay. Maybe I'll file and fix the separate issue about
removing the obsolete info from that topic first, before I deal with the in-memory DB doc.

One question about DERBY-4428 -- I notice when I try out the drop attribute in ij I get the
following error:

ij> CONNECT 'jdbc:derby:memory:dummy;drop=true';
ERROR 08006: Database 'memory:dummy' dropped.

This is the expected not-really-error when you shut down a database, so I guess it is getting
yet one more overload -- currently there are 8 messages associated with 08006 and now I guess
there will be one more. It seems to appear both when you shut the db down and when you drop
it. Is that correct?

It doesn't seem to be necessary to shut the db down before you drop it -- the drop seems to
accomplish both.

It appears that you can only use the drop attribute to drop an in-memory database, not a file-system
one. If I try the latter I get 

ij> connect 'jdbc:derby:firstdb;drop=true';
ERROR XBM0I: Directory firstdb cannot be removed.

That seems like a useful safeguard.

> Document the in-memory storage back end
> ---------------------------------------
>                 Key: DERBY-4525
>                 URL: https://issues.apache.org/jira/browse/DERBY-4525
>             Project: Derby
>          Issue Type: Task
>          Components: Documentation
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Assignee: Kim Haase
>             Fix For:
> The in-memory back end isn't considered experimental anymore, we have to 
> write user documentation for the feature(s).
> I'm not  sure how it should be structured, and where the content should be added.
> Just as a rough cut, here are a few possible topics (I'm not sure if all should be included
or not):
> - documenting the new protocol name ('memory')
> - documenting the new 'drop' JDBC connection URL attribute
> - describing the limitations of the feature (all your data will be lost if..., how to
use it with the client driver and the data sources)
> - "advanced use" (pull dbs on disk into memory, backup in-memory dbs to disk)
> - tuning tips (there are some issues with extreme page cache sizes, maybe the existing
content on page size is valid)
> - known problems (nothing concrete here yet, but we have one inquiry about disappearing
databases - the current theory is that different class loaders are used)
> Some more information is available at http://wiki.apache.org/db-derby/InMemoryBackEndPrimer

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

View raw message