[
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-3b-canonical_name_handling.diff
Attached patch 3b, and committed it to trunk with revision 884105.
I chose not to rename the method argument to canonicalServiceName, as I don't
think this isn't strictly necessary. It would also mean that the argument names
in the interface and the implementation would differ (not a problem by itself,
but might cause some confusion). That said, the monitor code (and friends) is
confusing on this matter - do you have to use the canonical service name, or
will the code obtain the canonical service name for you? I observe that the
latter is the case in many places, but I haven't gone through the code to
confirm this is the principle behind the code.
I need to make a few adjustments to patch 2a, and then the drop functionality
will be working - although not very well in cases where there are concurrent
connection attempts to the database being dropped.
> 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: 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-4428-0a-preview_patch.diff,
> derby-4428-1a-in_memory_specific_delete_code.diff,
> derby-4428-1a-in_memory_specific_delete_code.stat,
> derby-4428-1b-in_memory_specific_delete_code.diff,
> derby-4428-2a-generic_db_drop.diff,
> derby-4428-3a-canonical_name_handling.diff,
> derby-4428-3b-canonical_name_handling.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.
