[
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:
[hidden email]):
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
Locked
