Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 69096 invoked from network); 4 Feb 2009 23:58:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Feb 2009 23:58:27 -0000 Received: (qmail 2769 invoked by uid 500); 4 Feb 2009 23:58:25 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 2720 invoked by uid 500); 4 Feb 2009 23:58:25 -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 2666 invoked by uid 99); 4 Feb 2009 23:58:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Feb 2009 15:58:25 -0800 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, 04 Feb 2009 23:58:21 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DDDB7234C4A7 for ; Wed, 4 Feb 2009 15:57:59 -0800 (PST) Message-ID: <325730598.1233791879907.JavaMail.jira@brutus> Date: Wed, 4 Feb 2009 15:57:59 -0800 (PST) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Assigned: (DERBY-4048) Update Statistics code in AlterTableConstantAction should use execute transaction rather than compile transaction In-Reply-To: <205356353.1233760800170.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-4048: -------------------------------------- Assignee: Mamta A. Satoor > Update Statistics code in AlterTableConstantAction should use execute transaction rather than compile transaction > ----------------------------------------------------------------------------------------------------------------- > > Key: DERBY-4048 > URL: https://issues.apache.org/jira/browse/DERBY-4048 > Project: Derby > Issue Type: Improvement > Components: SQL > Affects Versions: 10.5.0.0 > Reporter: Mamta A. Satoor > Assignee: Mamta A. Satoor > Attachments: DERBY4048_useExecuteTran_diff.txt > > > DERBY-269 provided a new stored procedure SYSCS_UTIL.SYSCS_UPDATE_STATISTICS to update the statistics. The code to do the work was added in AlterTableConstantAction and the name of new method in that class is updateStatistics(Activation activation). This code was copied from an existing unused class execute/UpdateStatisticsConstantAction.java(that unused class has been removed from Derby code). > The copied code in AlterTableConstantAction:updateStatistics gets compile transaction as shown below to do the work of updating the statistics. > TransactionController tc = lcc.getTransactionCompile(); > The javadoc for LangaugeConnectionContext for getTransactionCompile says following > /** > Get the transaction controller to use with this language connection > context at compile time. > */ > TransactionController getTransactionCompile(); > I think we should be using TransactionController tc = lcc.getTransactionExecute() to do the work since we are not in the compile phase. The rest of the code in AlterTableConstantAction uses lcc.getTransactionExecute to get the transaction controller. > I will make the changes in AlterTableConstantAction.updateStatistics to use getTransactionExecute and will run the existing tests to make sure nothing breaks. > I ran into this issue of getTransactionExecute vs getTransactionCompile while working on DERBY-3788 (provide a zero-admin way of updating the statistics). While trying to run the statistics inline duirn the compile phase of a SELECT query, I ran into exception that statistics can't be updated because we are in read-only mode. But if I change the AlterTableConstantAction to use getTransactionExecute, then I do not run into the read-only mode exception. > Please let me know if anyone has any comments on this. I will run the existing tests and if no failures, then I will go ahead and commit the change of using getTransactionExecute rather than getTransactionCompile in AlterTableConstantAction:updateStatistics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.