[ https://issues.apache.org/jira/browse/OFBIZ-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678980#comment-13678980 ]
Adrian Crum edited comment on OFBIZ-5216 at 6/9/13 9:27 AM: ------------------------------------------------------------ Fixed, rev 1491165. For anyone who is interested: org.ofbiz.entity.jdbc.ConnectionFactory.java attempted to create singleton ConnectionFactoryInterface instances using a double-check-lock (DCL) design. That design is flawed and cannot guarantee a single instance. When OFBiz starts, it will create multiple component loader threads based on the number of CPUs. When it came time to create a single ConnectionFactoryInterface instance, the multiple threads would each create their own instance instead of a single shared instance (due to the flawed DCL code). I was able to reproduce the failed singleton instance 90% of the time. In rev 1490541 I replaced the DCL code with java.util.concurrent.atomic.AtomicReference. With that change, the singleton ConnectionFactoryInterface instance was guaranteed. The single ConnectionFactoryInterface instance caused a thread deadlock while loading the MSSQL JDBC driver; Derby and Postgres were unaffected. I wrapped the JDBC driver loading code with a synchronization block and that seems to fix the problem reported in this issue. was (Author: adri...@hlmksw.com): Fixed, rev 1491165. For anyone who is interested: org.ofbiz.entity.jdbc.ConnectionFactory.java attempted to create singleton ConnectionFactoryInterface instances using a double-check-lock (DCL) design. That design is flawed and cannot guarantee a single instance. When OFBiz starts, it will create mutiple component loader threads based on the number of CPUs. When it came time to create a single ConnectionFactoryInterface instance, the multiple threads would each create their own instance instead of a single shared instance (due to the flawed DCL code). I was able to reproduce the failed singleton instance 90% of the time. In rev 1490541 I replaced the DCL code with java.util.concurrent.atomic.AtomicReference. With that change, the singleton ConnectionFactoryInterface instance was guaranteed. The single ConnectionFactoryInterface caused a thread deadlock while loading the MSSQL JDBC driver; Derby and Postgres were unaffected. I wrapped the JDBC driver loading code with a synchronization block and that seems to fix the problem reported in this issue. > The thread is locked at DBCPConnectionFactory.getConnection() when connects > to multiple databases > ------------------------------------------------------------------------------------------------- > > Key: OFBIZ-5216 > URL: https://issues.apache.org/jira/browse/OFBIZ-5216 > Project: OFBiz > Issue Type: Bug > Components: framework > Affects Versions: SVN trunk > Reporter: Wei Zhang > Assignee: Adrian Crum > Priority: Blocker > Fix For: SVN trunk > > Attachments: entityengine.xml, jsconsole2.png, jsconsole.png, > jtds-1.2.5.jar, OFBIZ-5216.patch, OFBIZ-5216.zip, > postgresql-9.0-801.jdbc4.jar, screen.png > > > I connected 5 databases, ofbiz, ofbiz_olap, ofbiz_tenant and 2 MSSQL > databases of myself. Three ofbiz databases were created in Postgres. But the > the thread will locked at DBCPConnectionFactory.getConnection() when OFBiz > was starting. > And I changed > public Connection getConnection(GenericHelperInfo helperInfo, JdbcElement > abstractJdbc) throws SQLException, GenericEntityException > to > public synchronized Connection getConnection(GenericHelperInfo > helperInfo, JdbcElement abstractJdbc) throws SQLException, > GenericEntityException > it then works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira