commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hulley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DBCP-352) Repeated calls to getMetadata in a transaction leads to performance degredation
Date Thu, 10 Feb 2011 11:30:57 GMT

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

Derek Hulley commented on DBCP-352:
-----------------------------------

Results of running DBCPMetadataTest before and after applying trivial patch:

Before:

Found table dbcp_test
Inserted 5000 rows with average of 0ms per row.  Issued 0 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 0 metadata queries per insert.
Inserted 5000 rows with average of 2ms per row.  Issued 5 metadata queries per insert.
Inserted 10000 rows with average of 1ms per row.  Issued 5 metadata queries per insert.
Inserted 5000 rows with average of 5ms per row.  Issued 10 metadata queries per insert.
Inserted 10000 rows with average of 2ms per row.  Issued 10 metadata queries per insert.
Inserted 5000 rows with average of 8ms per row.  Issued 15 metadata queries per insert.
Inserted 10000 rows with average of 4ms per row.  Issued 15 metadata queries per insert.
Inserted 5000 rows with average of 11ms per row.  Issued 20 metadata queries per insert.
Inserted 10000 rows with average of 5ms per row.  Issued 20 metadata queries per insert.

After:

Found table dbcp_test
Inserted 5000 rows with average of 0ms per row.  Issued 0 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 0 metadata queries per insert.
Inserted 5000 rows with average of 0ms per row.  Issued 5 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 5 metadata queries per insert.
Inserted 5000 rows with average of 0ms per row.  Issued 10 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 10 metadata queries per insert.
Inserted 5000 rows with average of 0ms per row.  Issued 15 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 15 metadata queries per insert.
Inserted 5000 rows with average of 0ms per row.  Issued 20 metadata queries per insert.
Inserted 10000 rows with average of 0ms per row.  Issued 20 metadata queries per insert.

As is evident, the overhead of getMetadata() calls has disappeared.  The "memory leak" will
have gone, too.
Similar results are obtained for other unit tests with long-running transactions.

> 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, commons-dbcp-1.4-patched.diff
>
>
> 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

        

Mime
View raw message