[ 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