[
https://issues.apache.org/jira/browse/OFBIZ-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333778#comment-15333778 ]
Jacques Le Roux commented on OFBIZ-7346:
----------------------------------------
After noticing the Connection Pool Status feature in webtools was broken in trunk (also in R15.12 and R14.12) I checked the connection pooling in our stable release (R13.07 where the Connection Pool Status feature still works) and there it seems the connection pooling is still working correctly. I say it seems because I only checked with *Derby* locally and on the demo.
On stable demo we have currently 4 connections in the pool with 2 idle. Of course this varies, but I checked at several moments and the pool does not tend to 0 as in trunk with postgres when the patch is not applied.
Now the weird thing, if the Connection Pool Status feature reports correctly, then you can now also see that the pooling seems to work on trunk demo (after committing for OFBIZ-7363, I also restarted the trunk demo, wich is currently quite slow BTW). I need to revisit the whole thing...
> 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
