[
https://issues.apache.org/jira/browse/ARTEMIS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217414#comment-17217414
]
Mikko commented on ARTEMIS-2955:
--------------------------------
I have not seen any critical issues with performance, but I have to admit that
I could not really compare to the version before dbcp2. It was just unusable in
our environment.
One thing that came to my mind is whether this is actually related to dbcp2 as
such, but connection pooling in general. Could it be that the issue actually is
that we are now using datasource properly and return connections to the pool
after use, and can't rely on single active db connection that is used forever.
Therefore it can't be expected that the connection would have active prepared
statements, but these have to be prepared again whenever the connection is
borrowed from the pool. I'm not sure if this is the issue, but could well be.
Kind of a drawback when using connection pool and not rely on single active db
connection that is used forever.
> commons-dbcp2 performance issue with Derby Embedded DBMS
> --------------------------------------------------------
>
> Key: ARTEMIS-2955
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2955
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Tests
> Affects Versions: 2.16.0
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Attachments: image-2020-10-20-09-08-45-390.png,
> image-2020-10-20-09-10-10-644.png, pooling_off.svg, pooling_on.svg,
> screenshot-1.png
>
>
> The test suite has shown an increase in duration of 30 minutes going from to
> 2:30 to 3 hours: it seems related to integration paging tests running on
> Embedded Derby with the changes of
> [ARTEMIS-2823|https://issues.apache.org/jira/browse/ARTEMIS-2823].
> After some profiling sessions on
> org/apache/activemq/artemis/tests/integration/paging/PagingTest.testQueueRemoveAll
> it seems that using commons-dbcp2 with Embedded Derby isn't working as
> expected:
> !image-2020-10-20-09-08-45-390.png!
> while, if we switch to
> [EmbeddedDataSource|https://db.apache.org/derby/docs/10.13/publishedapi/org/apache/derby/jdbc/EmbeddedDataSource.html]
> we have
> !image-2020-10-20-09-10-10-644.png!
> By not using commons-dbcp2 we get roughtly a ~10X improvement in performance:
> it seems that commons-dbcp2 is forcing to setup from the ground the prepared
> statement each time, while EmbeddedDataSource nope. Specifically it seems
> related to Derby GenericActivationHolder.
> I suggest to disable commons-dbcp2 for Derby and investigate if it could
> happen in a real broker too.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
