[
https://issues.apache.org/jira/browse/DBCP-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300039#comment-14300039
]
Phil Steitz commented on DBCP-432:
----------------------------------
Thanks for having a look, Adrian!
The problem we have here is that we need the sync protection around the
initialization block, which is just executed once, by the first thread that
tries to get a connection to the pool (or non-standardly, by a thread that
directly calls createDataSource). We only want that code executed once.
Once the datasource is created and initialized, we want subsequent calls to
return as fast as possible. That is why the DCL setup is there. What my patch
does is to delay setting the instance field until it is initialized fully. One
could argue that it is better to let the pre-loading happen while other
requests get served. The dbcp/pool setup is robust enough so that does not
cause problems.
> BasicDataSource createDataSource can return partially initialized DataSource
> ----------------------------------------------------------------------------
>
> Key: DBCP-432
> URL: https://issues.apache.org/jira/browse/DBCP-432
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Phil Steitz
> Attachments: DBCP-432-AtomicReference.patch, DBCP-432.patch
>
>
> The BasicDataSource instance variable, dataSource, is DCL-controlled in
> createDataSource; but within the sync block it is set directly and then
> subsequently initialized. Threads that request connections, or access
> createDataSource directly while initialization is in progress will get
> partially initialized dataSources. In particular, logWriters may be null and
> initial pool capacity may not be provisioned (if initialSize > 0).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
