[
https://issues.apache.org/jira/browse/OFBIZ-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334121#comment-15334121 ]
Jacques Le Roux commented on OFBIZ-7346:
----------------------------------------
I confirm pooling and report work correctly in R13.07 locally with Derby or Postgres .
Also, measured with the fixed Connection Pool Status feature this bug does not affect Derby (tested locally on trunk HEAD, with JMeter pushing 100 concurrent requests). Maybe the reason it went unnoticed so far.
On the other hand , adding the 2 parameters\[1\] Gareth suggested
{code}
factory.setRollbackOnReturn(false);
factory.setEnableAutoCommitOnReturn(false);
{code}
does not hurt in a Derby context and fixes the pool-minsize issue in both cases (Derby and Postgres). So I believe we should commit the patch because it at least fixes the pool-minsize issue and does not hurt in these in both cases.
I'd just ask a question to you [~gareth.carter]: why and how did you pick those parameters and only those?
\[1\]
https://commons.apache.org/proper/commons-dbcp/api-2.1.1/org/apache/commons/dbcp2/BasicDataSource.html* setRollbackOnReturn "Sets the flag that controls if a connection will be rolled back when it is returned to the pool if auto commit is not enabled and the connection is not read only."
* setEnableAutoCommitOnReturn "Sets the value of the flag that controls whether or not connections being returned to the pool will be checked and configured with Connection.setAutoCommit(true) if the auto commit setting is false when the connection is returned. It is true by default."
> connection pooling not working
> ------------------------------
>
> Key: OFBIZ-7346
> URL:
https://issues.apache.org/jira/browse/OFBIZ-7346> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: Trunk
> Reporter: Gareth Carter
> Assignee: Jacques Le Roux
> Priority: Minor
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as the close() method is called (outside of transaction) or the transaction is committed the connections are closed to the db server and not returned to the pool.
> I believe the issue is with org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. This will call rollback() when rollbackOnReturn is set to true even if the transaction is committed. This is because any connection wrappers extending org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At some point, this cached autoCommit is different from the underlying connection autoCommit. The rollback() method will throw an exception and the connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test with postgres but could not see this behaviour
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Locked
