db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4525) Document the in-memory storage back end
Date Wed, 10 Mar 2010 10:37:29 GMT

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

Knut Anders Hatlen commented on DERBY-4525:

It sounds like a bug to me if you're able to drop a file-system database on the server. (I
didn't get that message myself when I tried the same commands on trunk. Instead, it looked
like the drop attribute was ignored, and a new connection was opened. Still sounds like a
bug, though.)

The difference in the error messages comes from the way we process error messages on the client.
In the normal case, the server sends the message id, the message translated to the server's
locale and the arguments used to generate the message. The client passes this information
and information about its own locale back to the server by invoking a stored procedure. The
server then translates the message to the client's locale so that it can be displayed correctly.
However, when CONNECT fails, there is no connection on which the stored procedure can be invoked
in order to translate the message, so the client just dumps whatever information it got from
the server in the first run.

So, yes, the difference is expected, but probably not desirable. I'm not sure if we have a
JIRA tracking this problem.

> 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