[
https://issues.apache.org/jira/browse/DERBY-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680283#action_12680283
]
Kristian Waagan commented on DERBY-4084:
----------------------------------------
Rick wrote:
-----
Bryan raises the issue of how we distinguish the transient in-memory database
(implemented by Kristian's patch) from Cheng's implementation, which snapshots
the database to disk on exit.
-----
To clarify, I'm hoping to incorporate Cheng's features into the Derby code
line, possibly with help from Cheng himself. Note that the database won't be
saved to disk on exit by default, you have to set a property to do that (I
think in Cheng's patch it was a system property).
Regardless of whether such a feature is added or not, the database must be
considered transient. A crash or abnormal VM shutdown will cause [all] data to
be lost.
Also note that even without the specific feature mentioned, the user can
explicitly "snapshot" the database by invoking Derby's existing backup
routine(s), and then restore the database on boot/creation (for instance by
using the createFrom URL attribute). The difference between the save on exit
feature and the backup mechanism, is that the former is automatic on shutdown.
I don't think the existing backup routines can be easily invoked from the
in-memory storage engine.
Thanks for the comments so far, and keep'em coming ;)
> Determine the subSubProtocol name for the in-memory back end
> ------------------------------------------------------------
>
> Key: DERBY-4084
> URL: https://issues.apache.org/jira/browse/DERBY-4084
> Project: Derby
> Issue Type: Sub-task
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
>
> The community should agree on a name for the subSubProtocol for the in-memory
> back end. The name will be used in the connection URL, and it is the
> mechanism used to tell Derby to use the in-memory back end:
> jdbc:derby:subSubProtocol:dbName
> Two hot candidates are:
> o mem
> o memory
> The former is shorter, the latter is slightly more descriptive. If you have
> opinions on this, please post a comment.
> We should decide on this before we cut the branch for 10.5.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
