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