From derby-dev-return-74305-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Nov 25 14:14:03 2009 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 90140 invoked from network); 25 Nov 2009 14:14:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Nov 2009 14:14:03 -0000 Received: (qmail 57818 invoked by uid 500); 25 Nov 2009 14:14:03 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 57781 invoked by uid 500); 25 Nov 2009 14:14:03 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 57640 invoked by uid 99); 25 Nov 2009 14:14:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 14:14:03 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2009 14:14:00 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A66C5234C1EE for ; Wed, 25 Nov 2009 06:13:39 -0800 (PST) Message-ID: <298639565.1259158419680.JavaMail.jira@brutus> Date: Wed, 25 Nov 2009 14:13:39 +0000 (UTC) From: "Kristian Waagan (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-4428) Add proper delete mechanism for in-memory databases In-Reply-To: <1489278540.1256820119353.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ 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.