Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 2 Feb 2011 12:05:29 +0000 (UTC)
From: "Derek Hulley (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <2019138122.4912.1296648329070.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1621484529.2652.1296571528962.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Issue Comment Edited: (DBCP-352) Repeated calls to
 getMetadata in a transaction leads to performance degredation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DBCP-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989596#comment-12989596 ] 

Derek Hulley edited comment on DBCP-352 at 2/2/11 12:03 PM:
------------------------------------------------------------

The table is deliberately simple, so use your database of choice.  I'm not convinced that using an in-memory DB is the solution given that the test is designed to scale up to hundreds of thousands of insertions; it's probably better just to piggy back off a real DB.

      was (Author: derekhulley):
    The table is deliberately simple, so use your database of choice.
  
> Repeated calls to getMetadata in a transaction leads to performance degredation
> -------------------------------------------------------------------------------
>
>                 Key: DBCP-352
>                 URL: https://issues.apache.org/jira/browse/DBCP-352
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.2.2, 1.3.1, 1.4
>         Environment: PostgreSQL, MySQL, JDK 1.6
>            Reporter: Derek Hulley
>            Priority: Critical
>             Fix For: 1.3.1, 1.4.1
>
>         Attachments: DBCPMetadataTest.zip
>
>
> During long-running transactions that utilize conditional logic based on the database metadata, it is possible to get thousands of calls to Connection.getMetaData.  An ArrayList is built up containing objects which are never removed (this is the cause of DBCP-330).  However, the array is shared with all other PreparedStatements, so the array scan and modification time keeps rising as the transaction progresses.
> I will attempt to attach an Eclipse project; profiling (or even a few JStacks) will show that most of the time is spent scanning the cluttered and growing array for objects to remove.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira