[jira] Updated: (DBCP-352) Repeated calls to getMetadata in a transaction leads to performance degredation

["Derek Hulley (JIRA)" <ji...@apache.org>]

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

Derek Hulley updated DBCP-352:
------------------------------

    Attachment: DBCPMetadataTest.zip

Requires table:
   CREATE TABLE dbcp_test( val integer NOT NULL );

Example arguments:
jdbc:postgresql://localhost:5432/dbcptest
test
test
10000

Crank up the getMetaData calls and profile.  Once you've hit 100K getMetaData calls, things start looking really bad; CPU usage suffers.

> 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.4
>         Environment: PostgreSQL, MySQL, JDK 1.6
>            Reporter: Derek Hulley
>            Priority: Critical
>         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