[ 
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: 10.6.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kim Haase
>             Fix For: 10.6.0.0
>
>
> 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.

Reply via email to