db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4428) Add proper delete mechanism for in-memory databases
Date Thu, 29 Oct 2009 15:03:59 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-4428:

    Attachment: derby-4428-0a-preview_patch.diff

Attached patch 0a, which is a preview patch for implementing the database delete mechanism
through the JDBC connection URL.

The patch isn't pure, it contains a few other fixes and there are things that have to be addressed.
However, it should serve well as a point for discussion. Main parts of the patch:
 - implementation of the delete mechanism itself.
    Split into the in-memory specific part and the storage factory agnostic part. Also includes
additions of error messages and some constants.
 - refactoring of the URL attribute handling in EmbedConnection.
    BootActions now contain the code dealing with examining the attributes. I'm interested
in feedback on whether this is something worth keeping or not. Note that attribute parsing
is still spread around, for instance the "lower level" attributes like restoreFrom and createFrom
are handled elsewhere (store).
 - other changes to the VFMemSF, where I added a guard to avoid potential OOMEs when trying
to boot a lot of non-existing databases.
 - refactoring and addition of some new tests.

Some general issues to consider / note:
 - the delete mechanism is generic (all storage factories that is writable). Should the feature
be in-memory specific, or also be allowed for the on-disk back end?
 - authorization (currently it checks if the user is the database owner if authentication
is on, doesn't require SQL authorization to be on).
 - how to control/limit the creation of in-memory databases?
    (could be used for DoS attack on a server?)
 - the implementation of deletion isn't sufficient for on-disk databases where the log is
stored in a non-default location (logDevice=...).
 - I had to disable an assert due to a mismatch between canonical names (haven't investigated
too much yet, this part of the code still confuses me...)

I plan to split the changes into somewhat smaller patches before committing.

> Add proper delete mechanism for in-memory databases
> ---------------------------------------------------
>                 Key: DERBY-4428
>                 URL: https://issues.apache.org/jira/browse/DERBY-4428
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Services, Store
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: derby-4428-0a-preview_patch.diff
> The current mechanism for deleting in-memory databases isn't good enough, and a proper
one must be added.
> It is also important to be able to delete in-memory databases, since they occupy valuable
main memory that should be discarded when the database is no longer needed.
> I intend to implement the mechanism by using the JDBC connection URL:
> "jdbc:derby:memory:myDatabase;delete=true[;user=X;password=Y]
> The connection attempt will throw an exception in any case, either because the request
failed or because it succeeded.
> Reasons for a failure can be invalid user and/or password, lacking encryption attributes,
or conflicting attributes.
> For the time being, only the database owner will be allowed to delete databases (*note*:
do we have a way to control/limit in-memory database creation?)

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

View raw message